On Tue, Dec 22, 2015 at 07:54:19PM +0900, Takashi Sakamoto wrote: > Once the device is unmute, then it keeps the state regardless of > starting/stopping streams. If the vendor uses the unmute state to avoid > any noises at starting packet streaming, the device should automatically > be muted when starting streaming or after stopping streaming. The vendor unmutes this register when streaming is started for the first time after device initialisation. This is possibly due to noise suppression during the initial device setup although I have not verified this electrically. In my view we should do the same since this is the way the device is used (and therefore supported) on other operating systems. If we deviate from the way the vendor drives the interface we could introduce subtle side effects for no good reason. > I realize it means that unmute/mute are not related to streaming > functionality. Therefore, no reasons to implement it in streaming driver. We may have to agree to disagree on this point. Where possible we should, imho, drive the hardware according to the vendor's procedures. > >> I'd like to drop the code to send write transactions to the address, and > >> leave the decision to userspace. ... > : > Please read fireface-proc.c or snd_ff_stream_get_clock() in > fireface-stream.c, then describe your opinion about the issue. snd_ff_stream_get_clock() is exclusively about identifying the clock source and rate. Some of this information is available in the read-only status registers starting at 0x801c0000 as you have found. However, deducing the rate from bits returned by a single quadlet read of 0x801c0004 is undocumented and in any case will not be accurate for some sync modes and clock sources. This means that some configuration needs persistent storage and the kernel driver is the logical place for this. As an aside, the status register content changes depending on the block read origin and request size. fireface-proc.c provides userspace with access to the status register, with the same access caveats as for snd_ff_stream_get_clock(). At this point I am inclined to just wait to see what lands and fix up the usability and interfacing issues later. Regards jonathan _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
