[alsa-devel] [PATCH] ALSA: usb: Work around CM6631 sample rate change bug
The C-Media CM6631 USB-to-S/PDIF receiver doesn't respond to changes in sampling frequency while the interface is active.
Reset the interface after setting the sampling frequency, to ensure that the sample rate set by snd_usb_init_sample_rate() is used. Otherwise, the device will try to use the sample rate of the previous file, causing distorted sound on sample rate changes.
Signed-off-by: Torstein Hegge hegge@resisty.net --- sound/usb/pcm.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index d82e378..01978a6 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -710,6 +710,16 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream *substream) subs->need_setup_ep = false; }
+ /* Some devices doesn't respond to sample rate changes while the + * interface is active. */ + switch (subs->stream->chip->usb_id) { + case USB_ID(0x0d8c, 0x0304): /* C-Media - Schiit USB Interface */ + case USB_ID(0x0d8c, 0x0309): /* C-Media CM6631 */ + usb_set_interface(subs->dev, subs->cur_audiofmt->iface, + subs->cur_audiofmt->altset_idx); + break; + } + /* some unit conversions in runtime */ subs->data_endpoint->maxframesize = bytes_to_frames(runtime, subs->data_endpoint->maxpacksize);
On 02.03.2013 14:04, Torstein Hegge wrote:
The C-Media CM6631 USB-to-S/PDIF receiver doesn't respond to changes in sampling frequency while the interface is active.
Reset the interface after setting the sampling frequency, to ensure that the sample rate set by snd_usb_init_sample_rate() is used. Otherwise, the device will try to use the sample rate of the previous file, causing distorted sound on sample rate changes.
Signed-off-by: Torstein Hegge hegge@resisty.net
Acked-by: Daniel Mack zonque@gmail.com
Thanks!
Daniel
sound/usb/pcm.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index d82e378..01978a6 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -710,6 +710,16 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream *substream) subs->need_setup_ep = false; }
- /* Some devices doesn't respond to sample rate changes while the
* interface is active. */- switch (subs->stream->chip->usb_id) {
- case USB_ID(0x0d8c, 0x0304): /* C-Media - Schiit USB Interface */
- case USB_ID(0x0d8c, 0x0309): /* C-Media CM6631 */
usb_set_interface(subs->dev, subs->cur_audiofmt->iface,subs->cur_audiofmt->altset_idx);break;- }
- /* some unit conversions in runtime */ subs->data_endpoint->maxframesize = bytes_to_frames(runtime, subs->data_endpoint->maxpacksize);
On Sat, Mar 02, 2013 at 02:12:33PM +0100, Daniel Mack wrote:
On 02.03.2013 14:04, Torstein Hegge wrote:
The C-Media CM6631 USB-to-S/PDIF receiver doesn't respond to changes in sampling frequency while the interface is active.
Reset the interface after setting the sampling frequency, to ensure that the sample rate set by snd_usb_init_sample_rate() is used. Otherwise, the device will try to use the sample rate of the previous file, causing distorted sound on sample rate changes.
Signed-off-by: Torstein Hegge hegge@resisty.net
Acked-by: Daniel Mack zonque@gmail.com
While this does fix the sample rate change problem, it introduces a new problem. With at least one media player application (xbmc) this patch causes the usb sound card to not output sound when starting a video file. Skipping forward or backward in the video stream restores audio output.
I haven't yet been able to look into why this happens, or why xbmc behaves different from mplayer and vlc.
Torstein
sound/usb/pcm.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index d82e378..01978a6 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -710,6 +710,16 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream *substream) subs->need_setup_ep = false; }
- /* Some devices doesn't respond to sample rate changes while the
* interface is active. */- switch (subs->stream->chip->usb_id) {
- case USB_ID(0x0d8c, 0x0304): /* C-Media - Schiit USB Interface */
- case USB_ID(0x0d8c, 0x0309): /* C-Media CM6631 */
usb_set_interface(subs->dev, subs->cur_audiofmt->iface,subs->cur_audiofmt->altset_idx);break;- }
- /* some unit conversions in runtime */ subs->data_endpoint->maxframesize = bytes_to_frames(runtime, subs->data_endpoint->maxpacksize);
At Sun, 3 Mar 2013 20:29:22 +0100, Torstein Hegge wrote:
On Sat, Mar 02, 2013 at 02:12:33PM +0100, Daniel Mack wrote:
On 02.03.2013 14:04, Torstein Hegge wrote:
The C-Media CM6631 USB-to-S/PDIF receiver doesn't respond to changes in sampling frequency while the interface is active.
Reset the interface after setting the sampling frequency, to ensure that the sample rate set by snd_usb_init_sample_rate() is used. Otherwise, the device will try to use the sample rate of the previous file, causing distorted sound on sample rate changes.
Signed-off-by: Torstein Hegge hegge@resisty.net
Acked-by: Daniel Mack zonque@gmail.com
While this does fix the sample rate change problem, it introduces a new problem. With at least one media player application (xbmc) this patch causes the usb sound card to not output sound when starting a video file. Skipping forward or backward in the video stream restores audio output.
I haven't yet been able to look into why this happens, or why xbmc behaves different from mplayer and vlc.
If the reset of interface is needed only when *changing* SRC, we can check the current rate against the previous rate and skip the reset?
The difference of xbmc and mplayer/vlc may come from the different initialization procedure. Apps can call hw_params or prepare multiple times, for example, before actually starting the stream.
Takashi
Torstein
sound/usb/pcm.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index d82e378..01978a6 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -710,6 +710,16 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream *substream) subs->need_setup_ep = false; }
- /* Some devices doesn't respond to sample rate changes while the
* interface is active. */- switch (subs->stream->chip->usb_id) {
- case USB_ID(0x0d8c, 0x0304): /* C-Media - Schiit USB Interface */
- case USB_ID(0x0d8c, 0x0309): /* C-Media CM6631 */
usb_set_interface(subs->dev, subs->cur_audiofmt->iface,subs->cur_audiofmt->altset_idx);break;- }
- /* some unit conversions in runtime */ subs->data_endpoint->maxframesize = bytes_to_frames(runtime, subs->data_endpoint->maxpacksize);
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Takashi Iwai wrote:
Torstein Hegge wrote:
On Sat, Mar 02, 2013 at 02:12:33PM +0100, Daniel Mack wrote:
On 02.03.2013 14:04, Torstein Hegge wrote:
The C-Media CM6631 USB-to-S/PDIF receiver doesn't respond to changes in sampling frequency while the interface is active.
- case USB_ID(0x0d8c, 0x0304): /* C-Media - Schiit USB Interface */
- case USB_ID(0x0d8c, 0x0309): /* C-Media CM6631 */
There are other CM6631-based devices.
If the reset of interface is needed only when *changing* SRC, we can check the current rate against the previous rate and skip the reset?
Or, if we want to be more similar to what many Windows drivers do, reset the interface to altsetting zero before setting it again.
Regards, Clemens
On Mon, Mar 04, 2013 at 11:31:59AM +0100, Clemens Ladisch wrote:
Takashi Iwai wrote:
Torstein Hegge wrote:
On Sat, Mar 02, 2013 at 02:12:33PM +0100, Daniel Mack wrote:
On 02.03.2013 14:04, Torstein Hegge wrote:
The C-Media CM6631 USB-to-S/PDIF receiver doesn't respond to changes in sampling frequency while the interface is active.
- case USB_ID(0x0d8c, 0x0304): /* C-Media - Schiit USB Interface */
- case USB_ID(0x0d8c, 0x0309): /* C-Media CM6631 */
There are other CM6631-based devices.
Most CM6631 devices with sample rate change problems reported has one of those two ids, as far as I can see. The Asus Xonar Essence One uses the CM6631, but it is listed in the wiki as supported, without any comments about any such issue. I don't know what vendor/product id the Emotiva XDA-2 reports. Did you think of any device in particular?
If the reset of interface is needed only when *changing* SRC, we can check the current rate against the previous rate and skip the reset?
Or, if we want to be more similar to what many Windows drivers do, reset the interface to altsetting zero before setting it again.
I see that is done other places in the usb module where the intention is to reset the device. It doesn't seem to make any difference one way or the other in this case. I'll do a reset to altsetting zero first in the next version of this patch.
Thanks.
Torstein
Torstein Hegge wrote:
On Mon, Mar 04, 2013 at 11:31:59AM +0100, Clemens Ladisch wrote:
On 02.03.2013 14:04, Torstein Hegge wrote:
- case USB_ID(0x0d8c, 0x0304): /* C-Media - Schiit USB Interface */
- case USB_ID(0x0d8c, 0x0309): /* C-Media CM6631 */
There are other CM6631-based devices.
Most CM6631 devices with sample rate change problems reported has one of those two ids, as far as I can see. The Asus Xonar Essence One uses the CM6631, but it is listed in the wiki as supported, without any comments about any such issue.
I vaguely remember some such report. Better add this (0b05:17a8).
I don't know what vendor/product id the Emotiva XDA-2 reports.
From that driver's .inf file:
%CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0301&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0302&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0304&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0305&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0306&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0309&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0310&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0311&MI_00 ;CM6610A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0312&MI_00 ;CM6620A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0313&MI_00 ;CM6630A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0314&MI_00 ;CM6631A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0319&MI_00 ;CM6631A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0315&MI_00 ;CM6632A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_200C&PID_1030&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_054C&PID_06CF&MI_00
(200c = Reloop, 054c = Sony)
Regards, Clemens
On Tue, Mar 05, 2013 at 08:55:03AM +0100, Clemens Ladisch wrote:
Torstein Hegge wrote:
On Mon, Mar 04, 2013 at 11:31:59AM +0100, Clemens Ladisch wrote:
On 02.03.2013 14:04, Torstein Hegge wrote: > + case USB_ID(0x0d8c, 0x0304): /* C-Media - Schiit USB Interface */ > + case USB_ID(0x0d8c, 0x0309): /* C-Media CM6631 */
There are other CM6631-based devices.
Most CM6631 devices with sample rate change problems reported has one of those two ids, as far as I can see. The Asus Xonar Essence One uses the CM6631, but it is listed in the wiki as supported, without any comments about any such issue.
I vaguely remember some such report. Better add this (0b05:17a8).
I got an email from a Xonar user experiencing the problem. I'll add it.
I don't know what vendor/product id the Emotiva XDA-2 reports.
From that driver's .inf file:
%CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0301&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0302&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0304&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0305&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0306&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0309&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0310&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0311&MI_00 ;CM6610A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0312&MI_00 ;CM6620A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0313&MI_00 ;CM6630A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0314&MI_00 ;CM6631A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0319&MI_00 ;CM6631A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0315&MI_00 ;CM6632A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_200C&PID_1030&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_054C&PID_06CF&MI_00
(200c = Reloop, 054c = Sony)
I'm not quite sure how to interpret that. I guess most of those are similar devices that doesn't necessarily need this workaround?
Torstein
Torstein Hegge wrote:
On Tue, Mar 05, 2013 at 08:55:03AM +0100, Clemens Ladisch wrote:
From that driver's .inf file:
%CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0301&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0302&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0304&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0305&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0306&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0309&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0310&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0311&MI_00 ;CM6610A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0312&MI_00 ;CM6620A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0313&MI_00 ;CM6630A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0314&MI_00 ;CM6631A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0319&MI_00 ;CM6631A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0315&MI_00 ;CM6632A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_200C&PID_1030&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_054C&PID_06CF&MI_00
I'm not quite sure how to interpret that. I guess most of those are similar devices that doesn't necessarily need this workaround?
Those are all the IDs that the C-Media driver attaches to. The hardware is always the same; I would be surprised if the firmware did not have the same bug.
Regards, Clemens
On Tue, Mar 05, 2013 at 11:35:35AM +0100, Clemens Ladisch wrote:
Torstein Hegge wrote:
On Tue, Mar 05, 2013 at 08:55:03AM +0100, Clemens Ladisch wrote:
From that driver's .inf file:
%CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0301&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0302&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0304&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0305&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0306&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0309&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0310&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0311&MI_00 ;CM6610A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0312&MI_00 ;CM6620A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0313&MI_00 ;CM6630A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0314&MI_00 ;CM6631A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0319&MI_00 ;CM6631A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0315&MI_00 ;CM6632A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_200C&PID_1030&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_054C&PID_06CF&MI_00
I'm not quite sure how to interpret that. I guess most of those are similar devices that doesn't necessarily need this workaround?
Those are all the IDs that the C-Media driver attaches to. The hardware is always the same; I would be surprised if the firmware did not have the same bug.
The ids listed covers CM6610, CM6620 and CM6631, which are distinct pieces of hardware, or at least they are sold as if they were. It might be a fair assumption that all current C-Media UAC V2.0 devices have this issue. However, I'm not able to test with anything other than CM6631.
The complete list then looks like:
switch (chip->usb_id) { /* C-Media CM6610/CM6620/CM6631 */ case USB_ID(0x054c, 0x06cf): /* Sony */ case USB_ID(0x0b05, 0x17a8): /* Asus Xonar Essence One */ case USB_ID(0x0d8c, 0x0301): case USB_ID(0x0d8c, 0x0302): case USB_ID(0x0d8c, 0x0304): /* CM6631 (Schiit) */ case USB_ID(0x0d8c, 0x0305): case USB_ID(0x0d8c, 0x0306): case USB_ID(0x0d8c, 0x0309): /* CM6631 */ case USB_ID(0x0d8c, 0x0310): case USB_ID(0x0d8c, 0x0311): /* CM6610A */ case USB_ID(0x0d8c, 0x0312): /* CM6620A */ case USB_ID(0x0d8c, 0x0313): /* CM6630A */ case USB_ID(0x0d8c, 0x0314): /* CM6631A */ case USB_ID(0x0d8c, 0x0315): /* CM6632A */ case USB_ID(0x0d8c, 0x0319): /* CM6631A */ case USB_ID(0x200c, 0x1030): /* Reloop */ [...] }
Torstein
Torstein Hegge wrote:
On Tue, Mar 05, 2013 at 11:35:35AM +0100, Clemens Ladisch wrote:
Torstein Hegge wrote:
On Tue, Mar 05, 2013 at 08:55:03AM +0100, Clemens Ladisch wrote:
From that driver's .inf file:
%CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0301&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0302&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0304&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0305&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0306&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0309&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0310&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0311&MI_00 ;CM6610A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0312&MI_00 ;CM6620A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0313&MI_00 ;CM6630A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0314&MI_00 ;CM6631A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0319&MI_00 ;CM6631A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_0D8C&PID_0315&MI_00 ;CM6632A %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_200C&PID_1030&MI_00 %CMUACWO.DeviceDesc%=CMUACWO,USB\VID_054C&PID_06CF&MI_00
I'm not quite sure how to interpret that. I guess most of those are similar devices that doesn't necessarily need this workaround?
Those are all the IDs that the C-Media driver attaches to. The hardware is always the same; I would be surprised if the firmware did not have the same bug.
The ids listed covers CM6610, CM6620 and CM6631, which are distinct pieces of hardware, or at least they are sold as if they were.
All the same chip with different labels. I don't know if C-Media even bothers to fuse off the unused features in the lower models.
It might be a fair assumption that all current C-Media UAC V2.0 devices have this issue.
Indeed. In any case, re-setting the interface should not hurt *any* compliant device.
Regards, Clemens
On Mon, Mar 04, 2013 at 09:53:54AM +0100, Takashi Iwai wrote:
At Sun, 3 Mar 2013 20:29:22 +0100, Torstein Hegge wrote:
While this does fix the sample rate change problem, it introduces a new problem. With at least one media player application (xbmc) this patch causes the usb sound card to not output sound when starting a video file. Skipping forward or backward in the video stream restores audio output.
I haven't yet been able to look into why this happens, or why xbmc behaves different from mplayer and vlc.
If the reset of interface is needed only when *changing* SRC, we can check the current rate against the previous rate and skip the reset?
That's right. I tried that, and it appears to have solved the issue with xbmc. I'll clean up that code and send an updated patch.
Thanks.
Torstein
participants (4)
-
Clemens Ladisch -
Daniel Mack -
Takashi Iwai -
Torstein Hegge