[LAU] Dual Delta Setup

Devin Anderson surfacepatterns at gmail.com
Sun Dec 30 23:50:51 UTC 2012


On Sun, Dec 30, 2012 at 3:33 PM, Fons Adriaensen <fons at linuxaudio.org> wrote:
> On Sun, Dec 30, 2012 at 07:27:11PM +0000, Ben Bell wrote:
>> On Sun, Dec 30, 2012 at 02:46:11PM +0000, Fons Adriaensen wrote:
>> > You could try zita-a2j instead of alsa-in. On my old 2G P4 machine
>> > adding 8 channels that way takes 10% CPU. Sound quality is vastly
>> > better than alsa-in.
>>
>> It's a vast improvement in terms of CPU usage. About 6% cpu vs about 24%.
>
> I *could* add a no-resample option, to be used only if the cards
> have the same sample clock...  Would probably reduce CPU use to
> less than 1%.
>
> But normally in that case you don't need a2j or j2a, the
> ALSA layer should be able to handle it by merging the two
> cards, and without any added latency as not only the sample
> clocks but also the periods would be synchronized.
>
> I've no idea why this fails as you mentioned in the
> message that started this thread.

We were discussing this on the JACK mailing list for a while, and I
eventually brought this up with the ALSA developers, but the
discussion didn't really go anywhere.

The (not-working) solution in ALSA is to use a 'multi' device.  The
problem is that the multi device returns poll descriptors for only one
device, and makes the assumption that when a period of data is
available on one device, there is a period of data available on the
other synced devices as well.  Unfortunately, in practice, this isn't
the case.  While snd_pcm_link() links the start, stop, drain, pause,
suspend, resume, reset, and prepare operations, it doesn't make the
readiness of the master device's poll descriptor depend on the
readiness of the poll descriptors of the slave devices.

So, you get a situation where poll() returns because there's data on
the master device, but then the 'multi' device indicates there's no
data because it checks all of the devices and returns the minimum
value for the amount of data available, which JACK thinks is an xrun
because the ALSA driver's wait function returns 0 when anything less
than a period's worth of data is available, and a 0 result is
interpreted as an xrun.  This results in tons and tons of xruns, as
JACK essentially busy waits until there is actually a period of data
available on all of the devices that make up the multi device.

-- 
Devin Anderson
surfacepatterns (at) gmail (dot) com

blog - http://surfacepatterns.blogspot.com/
midisnoop - http://midisnoop.googlecode.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/


More information about the Linux-audio-user mailing list