dsdreamer wrote: 
> With the latest version on the output branch, I am still having the
> problem that whenever I play a track at a higher sampling rate than the
> previously played track it fails (choppy Pinky and Perky sound), the
> instantaneous sample rate is an illegal value and the feedback format
> code is wrong. E.g., playing a 192kHz track right now (when I had
> previously been playing a 96kHz track), it sounds demented and has the
> following stream0
> > 
Code:
--------------------
  >   > 
  > Interface = 1
  > Altset = 1
  > URBs = 8 [ 8 8 8 8 8 8 8 8 ]
  > Packet Size = 1024
  > Momentary freq = 383838 Hz (0x2f.fad0)
  > Feedback Format = 17.15
  > 
--------------------
> > 
> If I play a 44.1kHz track and then go back to play that same 192kHz
> track, things get even more extreme:
> > 
Code:
--------------------
  >   > 
  > Playback:
  > Status: Running
  > Interface = 1
  > Altset = 1
  > URBs = 8 [ 8 8 8 8 8 8 8 8 ]
  > Packet Size = 1024
  > Momentary freq = 767727 Hz (0x5f.f740)
  > Feedback Format = 18.14
  > 
--------------------
> > 
> Switching down from a higher sample rate to a lower one is never a
> problem. 
> 
> I have tried this also with mmap=0, with very similar results. In all
> cases, I can recover to correct playback by stopping the player with
> capital Q and pressing play again. I am invoking squeezelite as
> follows when testing mmap=0 > 
Code:
--------------------
  >   > ./squeezelite -a 40:::0 -o hw:CARD=UD501 -n SqueezeliteQUAD -u E
--------------------
> > 
> 
> I have tested the "-u E" resampling option and it works perfectly!   I
> can now listen to BBC radio live streams, and I observe that I get
> internal resampling from 32kHz to 44.1kHz which sounds fine for Radio
> 4. 
> 
> Thanks for your continued work on this topic.

Hum - so it seems to me there's a feedback message for the old format
stuck in the dac in such a way that opening the new stream lets the
linux kernel receive it and the (not so clever in my view) code in the
kernel to quess the feedback format then messes up.  By effectively
forcing the stream to open and then recover, we probably reopen the
device twice and hence don't get this.

The only real downside I see of starting the device with no data is the
error messages we see as recovery is required.  I wonder if these are
the lesser of the evils.


------------------------------------------------------------------------
Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=99395

_______________________________________________
unix mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/unix

Reply via email to