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

[Damien Zammit]

On 18/03/15 12:06, Takashi Sakamoto wrote:
> On 2015年03月17日 22:49, Damien Zammit wrote:
>> Can we include my mixer control into the driver?
> 
> Depends on the reason.
The reason for allowing the mixer clock source control in the kernel is
because it is *core* functionality to be able to decide where the sound
card gets its clock from.  It would be cumbersome and awkward if users
had to fire up an external userspace program just to configure the clock
source!  The only reason some sound cards have external userspace
programs to configure these extras is because no one has bothered to
implement them in the kernel yet. (Well that is my opinion).

>> 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 agree that my clock source mixer control is a separate issue,
but please don't underestimate the work Robin and I have done with
003amdtp:  We are informing you that it now works correctly for all
channels, so long as it is integrated into the driver correctly.  We
know this because we tested it thoroughly with a bus analyser to verify
that the expected patterns were being played into the device and I used
my ears to listen to the pure silence on the other channels when the
magic bit pattern was being played into the device, as well as using a
program to monitor the levels (zero).

>> 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.
I would not have been able to notice the difference in dropouts without
my mixer control enabled, so I think from a development point of view it
is useful to include the mixer control in-kernel. (another reason).

> 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.
Takashi, you have provided here the conditions for which -ETIMEDOUT
occurs.  I am asking how can we prevent the dropouts, not how it occurs.
Perhaps the dbc field is irrelevant for 00x ?  I don't know, please let
me know if there is anything I can dump for you to help find out.

Damien