linuxaudio.org

--f46d043743ef95437c04d21c6a07

Content-Type: text/plain; charset=ISO-8859-1
On Sun, Dec 30, 2012 at 8:50 PM, Len Ovens  wrote:
> ck sets the device up (sends sample rate and buffer size) doesn't

quoted text
> the multi device have to send that info to both devices? Wouldn't that

> start both at the same time? Making the difference between readiness

> within a sample? (I ask because I don't know) When the master restarts, is

> there any indication sent to the slave via s/pdif?

>

s/pdif won't carry that information.
when i studied the ALSA code for this years ago, it looked to me as though

even on a late 1990's CPU, you could still expect both devices to start

*within* 1 sample of each other.
the problem as it been described here, seems more to be:
> >

quoted text
> > 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.

>

so they can be off by 1 sample (for example) and this can happen. ALSA

needs to wait for the slowest/last of the linked devices, not the first. or

so it appears.
--f46d043743ef95437c04d21c6a07

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
On Sun, D=

ec 30, 2012 at 8:50 PM, Len Ovens <len@ovenwerks.net> wrote:=
ck sets the device up (sends sample rate and buffer size) doesn't

the multi device have to send that info to both devices? Wouldn't that<=

br>

start both at the same time? Making the difference between readiness

within a sample? (I ask because I don't know) When the master restarts,=

 is

there any indication sent to the slave via s/pdif?s/pdif won't carry that information.when i studied the ALSA co=

de for this years ago, it looked to me as though even on a late 1990's =

CPU, you could still expect both devices to start *within* 1 sample of each=

 other.

the problem as it been described here, seems more to be:=A0

quoted text
>

> So, you get a situation where poll() returns because there's data =

on

quoted text
> the master device, but then the 'multi' device indicates there=

's no

quoted text
> 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 le=

ss

quoted text
> than a period's worth of data is available, and a 0 result is

> interpreted as an xrun. =A0This results in tons and tons of xruns, as<=

br>

quoted text
> JACK essentially busy waits until there is actually a period of data

> available on all of the devices that make up the multi device.so they can be off by 1 sample (for example) and th=

is can happen. ALSA needs to wait for the slowest/last of the linked device=

s, not the first. or so it appears.

--f46d043743ef95437c04d21c6a07--