Re: Help with RME alsa driver

Bruce <abruceperson@xxxxxxxxx> · Mon, 09 Feb 2015 16:28:23 +1100



    Hi Adrian,

      
      OK. I have made some progress !

      I now have good sound using jackd. I have managed to get
      this working at both single and double speed.

      There are some weirdnesses I can't explain (below), however.

      
      Where does this leave us wrt alsa vanilla alsa playpack ?

      
      On 8/02/2015 8:14 AM, Adrian Knoth wrote:

    
      On Sat, Feb 07, 2015 at 03:54:43PM +1100, Bruce wrote:


          And we really need that jackd test to sort out userspace. ;)

        
        I attempted this today.
Aologies in advance, having never dealt wth jackd before I'm a
complete novice here.
Installed jackd packages, and VLC (a typical jack client ?).

      
      mplayer -ao jack or even more simple: jack_metro. Then use patchage or
qjackctl to connect the outputs to the ports.
    
    I have got qjackctl working. However, I discovered, eventually, that
    this wasn't the actual problem.

    The problem was I was starting jackd as root (to get the realtime),
    but vlc only runs as a user. That was why they couldn't see each
    other. It was also the reason for the dbus errors, as dbus had been
    started as a user by X.

    
    (I found this out the long way, getting everything working under
    root, with jack_metro and jack_lsp, then gong back to vlc and
    finding I wasn't allowed to run that as root, so then restarting
    everything as the user).

    jackd whinges about no realtime privileges. I'm sure there's a way
    around this, but that doesn't matter right now.

    
        *jackd -dalsa* comes back with an error about no reply from session
bus about reservation.

      
      apt-get install jackd1 to get rid of it.
    
    The arch installer, yaourt, cannot find a jackd1 package. It can see
    jackd2 and jack2-dbus.

    I solved this error by running jackd as a user.

    
        That appears to keep running, but VLC (with audio output set to
jack) results in no audio heard, or anything on hdspmixer.
I'm afraid this hasn't contributed much :(

      
      That was most likely because you didn't connect the ports. VLC by
default does exactly this.
    
    No, seems vlc defaults to connect ports 1 & 2 automatically it
    seems. It could do this once jackd was run by the same user.

    
    Now the weirdness:

    If I run single speed at jackd default of 48k sampling:

    
      If I tick "playback" in hdspmixer, the row with OUT1-64
        appears, if I tick "output" an unlabelled set 1-64
        appears. This naming is very confusing !  I will refer
        to the unlabelled row as % below, and the playback row as OUT,
        the input row as IN.

      
      if I connect to playback 1, hdspmixer shows output signal on
        OUT1, %1, In63 and %63. Sliders on channel 1 do nothing. Slider
        on %63 changes the output level. OUT63 slider does nothing.

      
      if I connect to playback 63, hdspmixer shows output signal on
        OUT63, In63 and %63. Sliders on both Out63 and %63 change the
        output level.
      every 2nd channel seems to be connected to 63, and the others
        to channel 64. ie 1,3,5...->63

      
    If I run double speed, 96k sampling, and tell jackd to do this
      too:

    
      if I connect to playback 1, hdspmixer shows output only on
        OUT1, %1 and In1. I can't hear it of course, as nothing to
        channel 63 (63 & 64 are the headphone jack on the card)

      
      if I connect to playback 63, hdspmixer shows output on OUT63,
        %63 and In63. Sliders on both Out63 and %63 change the output
        level.
    
    So, questions are:

    
      Why do things behave differently (and in fact, seems more
        correctly) at 96k ?  Was this some kludge to make default
        outputs easier ?

      
      Why do In level bars show output ? Aren't these for
        capture ? Seems like some sort of loopback happening.
      I'm assuming a hardware mixer on the card mixes playback and
        capture together to give the "output", eg. for a live
        perfomance, but for normal duplex operation all input sliders
        are set to 0 and the capture is sampled directly. 
      If all else fails, what is involved in writing a jack client,
        with 32 playbacks and 32 capture channels, with 32(24) bit words
        ?

      
        Just checking on your previous description:
We're modifying a new verson of the driver (eg. whatever's in my
arch kernel source) with an older hdspm_hw_pointer implementation,
then make install puts it back into our running kernel ?

      
    Still working on this. I'm still coming up to speed on arch linux,
    finding out where the source tree is, etc.

    
    I have setup ssh access, however, if it helps to have a play
    directly.

    IP 122.107.150.127

    SSH port 2200

    user "sounddev", pw "sounddev", root pw "sounddev"

    
        Exactly.


Cheers


    -- 
Cheers,
Bruce
  

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user