Re: [Alsa-user] Status of CM6631 USB

Re: [Alsa-user] Status of CM6631 USB

[Daniel Mack]

Hi Torstein,

(+ alsa-devel)

On 02.03.2013 12:09, Torstein Hegge wrote:
> Daniel Mack <zonque <at> gmail.com> writes:
>>>> This is a known bug, also most probably flaw in the CMEDIA chip, 
>>>> and not yet properly worked around in the snd-usb driver. If you 
>>>> want to investigate, have a look at the feedback format 
>>>> autodetection code in sound/usb/endpoint.c.
>>>
>>> Thanks, I'll have a look.
>>
>> I believe what's going on here is that the device is confused after
>> sample rate changes and keeps sending back feedback data for the old
>> rate on its feedback endpoint. That causes the autodetection algorithm,
>> which kicks in on every first packet of a stream, to go nuts, which
>> causes the part of the driver that sends the data assume a very wrong
>> rate. Some printk() there should give you a hint.
> 
> I had a look at this using another C-Media CM6631 based device, the Corda
> Daccord (usbid 0x0d8c, 0x0309). As far as I can see, what happens in the
> feedback format auto-detection is: 
> 
> When starting playback of a file with a different sampling frequency than the 
> previous file, the reported feedback frequency is in the same range as the 
> previously played file, varying within +-1%.
> 
> The feedback format detection gives a shift of -1 and reports the feedback
> frequency as ~48kHz when playing a 44.1kHz file after a 96kHz file. Same thing
> happens when playing a 96kHz file after a 44.1kHz file, the device reports
> feedback frequency in the 44.1kHz range, the feedback format detection gives a
> shift of +1 and reports the feedback frequency as ~88kHz.

That's what I suspected.

> Bypassing the feedback format detection by hard-coding the frequency shift to
> zero and setting the feedback frequency ep->freqm equal to the nominal
> frequency ep->freqn if the feedback frequency is far off from the expected
> value (like 48kHz when expecting 44.1kHz) does not change the distortion.
> 
> Similarly, forcing the feedback detection to run multiple times until it
> reaches an acceptable value just keeps the feedback detection to repeatedly
> until playback is stopped. This probably means any amount of skipping packages
> early in the stream won't work.

Ok.

> It seems like the device stays in the previous frequency until the interface
> is reset. One possible workaround is to call usb_set_interface() again after
> snd_usb_init_sample_rate(), like this:

I see - that also explains why explicitly stopping and restarting the
stream fixes the problem in most cases, right?

> 
> 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);
> 
> This fixes all problems related to sample rate changes for me. I have only
> tested with the Daccord, but it should work for the Schiit and other CM6631
> based devices as well.

Many thanks for looking into this! Much appreciated.

Could you cook a real patch please and send it to alsa-devel? Have a
look at Documentation/SubmittingPatches if that's your first submission.


Best,
Daniel

Re: Status of CM6631 USB

[chris hermansen]

[-- Attachment #1.1: Type: text/plain, Size: 4493 bytes --]

Gentlemen;


On Sat, Mar 2, 2013 at 4:21 AM, Daniel Mack <zonque@gmail.com> wrote:

> Hi Torstein,
>
> (+ alsa-devel)
>
> On 02.03.2013 12:09, Torstein Hegge wrote:
> > Daniel Mack <zonque <at> gmail.com> writes:
> >>>> This is a known bug, also most probably flaw in the CMEDIA chip,
> >>>> and not yet properly worked around in the snd-usb driver. If you
> >>>> want to investigate, have a look at the feedback format
> >>>> autodetection code in sound/usb/endpoint.c.
> >>>
> >>> Thanks, I'll have a look.
> >>
> >> I believe what's going on here is that the device is confused after
> >> sample rate changes and keeps sending back feedback data for the old
> >> rate on its feedback endpoint. That causes the autodetection algorithm,
> >> which kicks in on every first packet of a stream, to go nuts, which
> >> causes the part of the driver that sends the data assume a very wrong
> >> rate. Some printk() there should give you a hint.
> >
> > I had a look at this using another C-Media CM6631 based device, the Corda
> > Daccord (usbid 0x0d8c, 0x0309). As far as I can see, what happens in the
> > feedback format auto-detection is:
> >
> > When starting playback of a file with a different sampling frequency
> than the
> > previous file, the reported feedback frequency is in the same range as
> the
> > previously played file, varying within +-1%.
> >
> > The feedback format detection gives a shift of -1 and reports the
> feedback
> > frequency as ~48kHz when playing a 44.1kHz file after a 96kHz file. Same
> thing
> > happens when playing a 96kHz file after a 44.1kHz file, the device
> reports
> > feedback frequency in the 44.1kHz range, the feedback format detection
> gives a
> > shift of +1 and reports the feedback frequency as ~88kHz.
>
> That's what I suspected.
>
> > Bypassing the feedback format detection by hard-coding the frequency
> shift to
> > zero and setting the feedback frequency ep->freqm equal to the nominal
> > frequency ep->freqn if the feedback frequency is far off from the
> expected
> > value (like 48kHz when expecting 44.1kHz) does not change the distortion.
> >
> > Similarly, forcing the feedback detection to run multiple times until it
> > reaches an acceptable value just keeps the feedback detection to
> repeatedly
> > until playback is stopped. This probably means any amount of skipping
> packages
> > early in the stream won't work.
>
> Ok.
>
> > It seems like the device stays in the previous frequency until the
> interface
> > is reset. One possible workaround is to call usb_set_interface() again
> after
> > snd_usb_init_sample_rate(), like this:
>
> I see - that also explains why explicitly stopping and restarting the
> stream fixes the problem in most cases, right?
>
> >
> > 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);
> >
> > This fixes all problems related to sample rate changes for me. I have
> only
> > tested with the Daccord, but it should work for the Schiit and other
> CM6631
> > based devices as well.
>
> Many thanks for looking into this! Much appreciated.
>
> Could you cook a real patch please and send it to alsa-devel? Have a
> look at Documentation/SubmittingPatches if that's your first submission.
>

I would be happy to test this on my Schiit Bifrost as well.  I'm currently
using the TOSLINK connection but it would be easy peasy to hook up a laptop
via the USB.

-- 
Chris Hermansen · clhermansen "at" gmail "dot" com

C'est ma façon de parler.

[-- Attachment #1.2: Type: text/html, Size: 5514 bytes --]

[-- Attachment #2: Type: text/plain, Size: 238 bytes --]

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user