Re: Help with RME alsa driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ok. Huge progress.
Works for me too !

To get the 96k playback working too, I used :
aplay --buffer-size=128
Then it sounds perfect.
(Also -B 1250 works)

The weird channel mapping stuff continues in hdspmixer, so this is an unrelated problem. I suspect my C code will be unaffected.

In my code I simply used the buffer size from set_hwparams call in the call to set_swparams, as per alsa examples.
I had the requested time set to something huge (get as much as buffer possible).
I now have tried this set to 1250us, and it works. Even the callbacks came back to life !!

Weirdly, a call to usleep() seems to fall straight through on this arch box. Anyone have any idea what's going on there ?

So, I suspect somewhere in the set_hwparams call, the 128 buffer size limit should limit the buffer size returned if the time requested exceeds that. That should fix aplay etc.

Besides that, there is:
+The oddness with hdspmixer naming.
+The weirdness with the channel 1 activity when aplay is used, and differences in behavior when the rate changes between single & double speed. Tino also saw something like this.
My C code only talks correctly to the requested out channel, so this is an aplay & jack thing.

Note: the inputs showing activity with playback seems to be actually real. Perhaps if you don't have a MADI box at the address of the playback channel (31,32 in this case), the playback automatically loops back as it gets echoed around the loop ?

Cheers,
Bruce

On 9 Feb 2015 22:00, "Tino Mettler" <tino.mettler@xxxxxxxxxxxxx> wrote:
On Mon, 2015-02-09 at 09:18 +0100, Takashi Iwai wrote:
> At Mon, 09 Feb 2015 16:28:23 +1100,
> Bruce wrote:
> >
> > 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 ?
>
> Compare the hw_params setups found in
> /proc/asound/card*/pcm*/sub*/hw_params between jack and native-aplay.
> Then try aplay with the buffer size and period size via options.
> Possibly some hw constraints are missing, e.g. the alignment of buffer
> size with the period size.

Hi,

thanks for the hint. I tried aplay -B 2500 and output was fine.

$ grep "" /proc/asound/card2/pcm*/sub*/hw_params
/proc/asound/card2/pcm0c/sub0/hw_params:closed
/proc/asound/card2/pcm0p/sub0/hw_params:access: MMAP_NONINTERLEAVED
/proc/asound/card2/pcm0p/sub0/hw_params:format: S32_LE
/proc/asound/card2/pcm0p/sub0/hw_params:subformat: STD
/proc/asound/card2/pcm0p/sub0/hw_params:channels: 16
/proc/asound/card2/pcm0p/sub0/hw_params:rate: 48000 (48000/1)
/proc/asound/card2/pcm0p/sub0/hw_params:period_size: 64
/proc/asound/card2/pcm0p/sub0/hw_params:buffer_size: 128

It seems like buffer size 128 is the maximum, as distortions during
playback start with larger values.

Regards,
Tino


------------------------------------------------------------------------------
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

[Index of Archives]     [ALSA Devel]     [Linux Audio Users]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

  Powered by Linux