[alsa-devel] Can module snd-aloop (virtual looback device) be made clock slave of a real audio device ?
perex at perex.cz
Tue Aug 21 10:55:46 CEST 2012
Date 21.8.2012 10:28, James Warden wrote:
> ----- Original Message -----
> From: Jaroslav Kysela <perex at perex.cz>
> To: alsa-devel at alsa-project.org
> Cc: warjamy at yahoo.com
> Sent: Monday, August 20, 2012 12:26 PM
> Subject: Re: [alsa-devel] Can module snd-aloop (virtual looback device) be made clock slave of a real audio device ?
> Date 20.8.2012 11:51, James Warden wrote:
>>> Hello alsa-devel's,
>>> A while back, I had written a rather hackish method to hook up the
>>> ALSA virtual loopback device to jack (jackaudio.org) via Jack clients
>>> alsa_in / alsa_out so that non jack-aware applications that can
>>> however use ALSA devices "directly" (via alsa-lib) can have their
>>> audio stream redirected to jack (see my rather lengthy prose at
>>> There are a few advantages in this method (depends on your use-cases
>>> of course). But it could be improved (or so I think) by removing the
>>> following drawbacks:
>>> The alsa_in/out jack clients are resampling the audio stream to
>>> synchronize with the device that jack is using. The resampling, done
>>> by libsamplerate, takes some CPU power. Since many users are using my
>>> recipe on laptops, this is not always welcome.
>>> Because snd-aloop is a virtual device, couldn't it be made a clock
>>> slave of the h/w device that jack is operating on ? This would in
>>> principle remove the need for resampling. I could imagine that the
>>> module could be passed an option at loading time (e.g. modprobe
>>> snd-aloop clock-master=<real h/w device index> or something like
>> Use 'PCM Rate Shift 100000' mixer control to fine tune the rate (timing)
>> for the snd-aloop PCM devices. An example using this solution is the
>> alsaloop application from the alsa-utils package.
>> Also note that other controls can expose the audio format on the
>> playback side, so you can avoid resampling in the alsa-lib completely
>> for ALSA audio apps. The alsaloop application can give you more hints.
> Thanks for the hints!
> I have a few questions:
> 1- I can see the "PCM Rate Shift 100000" control when I list it with amixer.
> is there a way to have these (hidden) controls show up in alsamixer as well ?
No, it isn't, it's marked as a part of the PCM API, not mixer API. This
control was introduced to set the drift programatically.
> 2- The range of this control is 80%-120%. Do I understand that it is a constant ? Once set, it just stays there ?
This value can be changed (corrected) at any time.
> 3- How would I know which value I would have to set anyway ?
alsaloop measures the frequency from the real hardware and computes the
actual drift which is passed to snd-aloop. The drift is handled all
times (it's not just one shot measure).
> 4- something a bit orthogonal: my main card is a Hammerfall HDSP + Multiface II.
> The access mode is MAP_NONINTERLEAVED according to the hw_params. This prevents me from e.g. combining this card and the virtual loopback into one (not that I want to do that in the end but I was experimenting with the merge plugin at some point in the past) because the access mode is MAP_INTERLEAVED for snd-aloop. This also prevents the alsaloop utility from being used like in this example:
> alsaloop -C hw:Loopback,1,0 -P hw:DSP
> This fires up OK, but then when I try to play something on hw:Loopback,0,0, alsaloop gives up with an error message regarding the stream format being wrong or the like (I am not sitting at home now, so I can't say preceisely).
Use the plughw:DSP device which does the conversions.
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.
More information about the Alsa-devel