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