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