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

Takashi Sakamoto
2015-03-18T01:06:48Z

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