* [PATCH] ALSA: usb: Work around CM6631 sample rate change bug
@ 2013-03-02 13:04 Torstein Hegge
2013-03-02 13:12 ` Daniel Mack
0 siblings, 1 reply; 12+ messages in thread
From: Torstein Hegge @ 2013-03-02 13:04 UTC (permalink / raw)
To: alsa-devel
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);
--
1.7.10.4
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: usb: Work around CM6631 sample rate change bug
2013-03-02 13:04 [PATCH] ALSA: usb: Work around CM6631 sample rate change bug Torstein Hegge
@ 2013-03-02 13:12 ` Daniel Mack
2013-03-03 19:29 ` Torstein Hegge
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Mack @ 2013-03-02 13:12 UTC (permalink / raw)
To: Torstein Hegge; +Cc: alsa-devel
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);
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: usb: Work around CM6631 sample rate change bug
2013-03-02 13:12 ` Daniel Mack
@ 2013-03-03 19:29 ` Torstein Hegge
2013-03-04 8:53 ` Takashi Iwai
0 siblings, 1 reply; 12+ messages in thread
From: Torstein Hegge @ 2013-03-03 19:29 UTC (permalink / raw)
To: Daniel Mack; +Cc: alsa-devel
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);
> >
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: usb: Work around CM6631 sample rate change bug
2013-03-03 19:29 ` Torstein Hegge
@ 2013-03-04 8:53 ` Takashi Iwai
2013-03-04 10:31 ` Clemens Ladisch
2013-03-04 21:29 ` Torstein Hegge
0 siblings, 2 replies; 12+ messages in thread
From: Takashi Iwai @ 2013-03-04 8:53 UTC (permalink / raw)
To: Torstein Hegge; +Cc: alsa-devel, Daniel Mack
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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: usb: Work around CM6631 sample rate change bug
2013-03-04 8:53 ` Takashi Iwai
@ 2013-03-04 10:31 ` Clemens Ladisch
2013-03-04 21:33 ` Torstein Hegge
2013-03-04 21:29 ` Torstein Hegge
1 sibling, 1 reply; 12+ messages in thread
From: Clemens Ladisch @ 2013-03-04 10:31 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Torstein Hegge, alsa-devel, Daniel Mack
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: usb: Work around CM6631 sample rate change bug
2013-03-04 8:53 ` Takashi Iwai
2013-03-04 10:31 ` Clemens Ladisch
@ 2013-03-04 21:29 ` Torstein Hegge
1 sibling, 0 replies; 12+ messages in thread
From: Torstein Hegge @ 2013-03-04 21:29 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, Daniel Mack
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: usb: Work around CM6631 sample rate change bug
2013-03-04 10:31 ` Clemens Ladisch
@ 2013-03-04 21:33 ` Torstein Hegge
2013-03-05 7:55 ` Clemens Ladisch
0 siblings, 1 reply; 12+ messages in thread
From: Torstein Hegge @ 2013-03-04 21:33 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: Takashi Iwai, alsa-devel, Daniel Mack
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: usb: Work around CM6631 sample rate change bug
2013-03-04 21:33 ` Torstein Hegge
@ 2013-03-05 7:55 ` Clemens Ladisch
2013-03-05 10:22 ` Torstein Hegge
0 siblings, 1 reply; 12+ messages in thread
From: Clemens Ladisch @ 2013-03-05 7:55 UTC (permalink / raw)
To: Torstein Hegge; +Cc: Takashi Iwai, alsa-devel, Daniel Mack
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: usb: Work around CM6631 sample rate change bug
2013-03-05 7:55 ` Clemens Ladisch
@ 2013-03-05 10:22 ` Torstein Hegge
2013-03-05 10:35 ` Clemens Ladisch
0 siblings, 1 reply; 12+ messages in thread
From: Torstein Hegge @ 2013-03-05 10:22 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: Takashi Iwai, alsa-devel, Daniel Mack
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: usb: Work around CM6631 sample rate change bug
2013-03-05 10:22 ` Torstein Hegge
@ 2013-03-05 10:35 ` Clemens Ladisch
2013-03-05 21:24 ` Torstein Hegge
0 siblings, 1 reply; 12+ messages in thread
From: Clemens Ladisch @ 2013-03-05 10:35 UTC (permalink / raw)
To: Torstein Hegge; +Cc: Takashi Iwai, alsa-devel, Daniel Mack
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: usb: Work around CM6631 sample rate change bug
2013-03-05 10:35 ` Clemens Ladisch
@ 2013-03-05 21:24 ` Torstein Hegge
2013-03-05 21:39 ` Clemens Ladisch
0 siblings, 1 reply; 12+ messages in thread
From: Torstein Hegge @ 2013-03-05 21:24 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: Takashi Iwai, alsa-devel, Daniel Mack
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ALSA: usb: Work around CM6631 sample rate change bug
2013-03-05 21:24 ` Torstein Hegge
@ 2013-03-05 21:39 ` Clemens Ladisch
0 siblings, 0 replies; 12+ messages in thread
From: Clemens Ladisch @ 2013-03-05 21:39 UTC (permalink / raw)
To: Torstein Hegge; +Cc: Takashi Iwai, alsa-devel, Daniel Mack
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-03-05 21:41 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-02 13:04 [PATCH] ALSA: usb: Work around CM6631 sample rate change bug Torstein Hegge
2013-03-02 13:12 ` Daniel Mack
2013-03-03 19:29 ` Torstein Hegge
2013-03-04 8:53 ` Takashi Iwai
2013-03-04 10:31 ` Clemens Ladisch
2013-03-04 21:33 ` Torstein Hegge
2013-03-05 7:55 ` Clemens Ladisch
2013-03-05 10:22 ` Torstein Hegge
2013-03-05 10:35 ` Clemens Ladisch
2013-03-05 21:24 ` Torstein Hegge
2013-03-05 21:39 ` Clemens Ladisch
2013-03-04 21:29 ` Torstein Hegge
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).