* [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 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
* 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
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).