Re: [PATCH 11/11] ALSA: digi00x: apply double-oh-three algorism to multiplex PCM samples

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

On 2015年03月17日 22:49, Damien Zammit wrote:
> Can we include my mixer control into the driver?

Depends on the reason.

> I think it is important to include the clock source selector switch as
> an alsamixer setting.

Please explain the importance, especially the reason to include the 
selector into kernel code instead of userspace application.

> Every other serious soundcard allows clock source selection.

Over generalization.

Some ALSA drivers still expect userspace applications to implement this 
functionality.

> I tested 003R+ with Robin's suggestion of hacking the state to be
> statically initialised to zero (which won't work for multi devices),
> and the results were great: dead silence on channel 1 when playing into
> channel 18.  This small hack means that Robin's update to 003amdtp
> should work flawlessly when integrated into the driver properly.

What we need is to test Robin's new code thoroughly, not include extra 
functionality such as clock source selector unrelated to streaming 
functionality.

> Takashi:  I am also reporting that ADAT sync, SPDIF sync both work using
> my clock source selector control.  In fact, without the sync to external
> device, there are many dropouts in the 1394 streams.
> How can we address this issue?

In this case, the kernel driver should return error code to userspace 
application. If the driver cannot handle any in-packets after starting 
transmitted stream, it detects timeout (500msec) and return -ETIMEDOUT. 
If the in-packets include discontinuity of the value in dbc field of CIP 
header, ALSA AMDTP implementation detects it and stop transmitted 
stream, then the driver also returns -ETIMEDOUT.


Regards

Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel