jdb wrote:It smells a lot like dropped samples.
Your device is asynchronous, i.e. has a fixed internal clock on which samples are output at a fixed, independent frequency. Feedback reporting is used to maintain the source sample rate close to the rate at which the device is playing samples back.
There's something wonky with how ALSA interprets the timings on dwc_otg: you either get
a) the log filled with "delay: estimated 0, actual xxx" messages
b) sample rates that wander off to maximal or minimal values
c) dropped samples.
In your case, it appears that ALSA is feeding data too fast and your device drops samples.
I have a Soundblaster Extigy (courtesy of tvjon) that is also asynchronous but does something different: instead of dropping samples, it increases its own internal sample rate and thus everything plays back fast.
For the record, I've been testing today using a C-media CM108 device (7.1 channel, 16-bit 48khz or 96khz/16-bit 2-channel) which is adaptive: despite the spam due to (a) above, I can do duplex stereo record at the same time as 96k/16bit stereo playback.
Hi,
My HRT Music Streamer II seems to play fine with:
dwc_otg.fiq_enable=1 dwc_otg.fiq_fsm_enable=1 dwc_otg.fiq_fsm_mask=0x7
On the 9th April update e8d2ad3c208f374f1df5b059a5cb15cfccd874e1
It is one of the later updates that appears to cause the sound distortion (dropped samples).
Is the kernel update 3.12.17 the cause?
Any data I can supply to help troubleshoot?
Great work so far.
Thanks,
Gareth
.
