On Sat, 15 Aug 2015 00:19:41 +0200, Pierre-Louis Bossart wrote:
While trying to understand how asynchronous endpoints are supported, I identified two major issues. On my M-Audio transit, the following script tries to play using the 3 different endpoints supported and fails (error and no audio) after the first playback without the patches. With the patches on top of 4.1.5 or Takashi's for-next (4.2.0-rc5), I stopped the audio after an hour.
while true do aplay -d5 -Dhw:2,0 ~/16_48.wav # play 48kHz, 16 bit on async ep aplay -d5 -Dhw:2,0 ~/24_48.wav # play 48kHz, 24 bit on 'none'/async ep aplay -d5 -Dhw:2,0 ~/24_96.wav # play 96 kHz, 24 bit on adaptive ep aplay -d5 -Dhw:2,0 ~/24_48.wav aplay -d5 -Dhw:2,0 ~/16_48.wav aplay -d5 -Dhw:2,0 ~/24_96.wav done
The first issue is pretty bad with corrupted pointers. When transitioning from a alternate setting with a sync_endpoint to another which doesn't have one by construction (synchronous, adaptive, async on capture), the pointers are not reset and the code tries to set the parameters of a non-existent endpoint.
The second issue is that the M-audio Transit descriptors are illegal but the logic can be changed without harm.
I sometimes hear noise on playback start, probably the code needs to be changed to add enough silent samples to let the PLL lock. I haven't had time to work on this and this is more of an enhancement.
v2: applied Takashi's comments unconditional clean-up of sync_endpoint pointers better logical tests and removal of goto
Pierre-Louis Bossart (2): ALSA: usb: fix corrupted pointers due to interface setting change ALSA: usb: handle descriptor with SYNC_NONE illegal value
Applied both now. Thanks.
Takashi