mrw wrote: 
> Thank you very much for this. It shows much promise.
> 
> I've been testing the revised binary against the same problematic stream
> posted by @staresy. My results differ from yours, in that I have start
> up problems, due to buffer underruns, much as described by
> @expectingtofly. Once going, all seems to be fine, and I get very nicely
> filled buffers, much as you have described.
> 
> I'll say now, that  does seem to resolve the start up problems. I don't
> know what the 'proper' fix for this should be. And I don't know why you
> don't experience it while I and @expectingtofly do.
> 
> One other thing: under the original binary the problems (after initial
> start up issue) were accompanied by a curious log trace. Notice that the
> output buffer was thoroughly full, but still we got an underrun. I found
> that odd. I am not seeing this with the revised binary. I don't know
> what you did, but curing this may have been key.
> 
> > 
Code:
--------------------
  >   > 
  > Community release illustrating one very odd form of problem with aac 
problem stream
  > 
  > Output buffer well full, but suddenly “POP”
  > Feb 25 16:50:42 squeezeplay: INFO   audio.decode - Playback.lua:448 
100.0%/93.5%
  > Feb 25 16:50:43 squeezeplay: INFO   audio.decode - Playback.lua:448 
100.0%/96.5%
  > Feb 25 16:50:45 squeezeplay: INFO   audio.decode - Playback.lua:448 
100.0%/99.3%
  > Feb 25 16:50:45 squeezeplay: playback_callback:346 Audio underrun: used 138 
frames, requested 441 frames. elapsed samples 13659342
  > Feb 25 16:50:45 squeezeplay: INFO   audio.decode - Playback.lua:364 OUTPUT 
UNDERRUN
  > Feb 25 16:50:45 squeezeplay: DEBUG  audio.decode - decode_pause_audio:624 
decode_pause_audio interval_ms=0
  > Feb 25 16:50:45 squeezeplay: DEBUG  audio.decode - Playback.lua:855 strm p
  > Feb 25 16:50:45 squeezeplay: DEBUG  audio.decode - Playback.lua:1262 
stopping local pause timer
  > Feb 25 16:50:45 squeezeplay: DEBUG  audio.decode - decode_pause_audio:624 
decode_pause_audio interval_ms=0
  > Feb 25 16:50:45 squeezeplay: DEBUG  audio.decode - 
decode_pause_audio_handler:156 decode_pause_handler interval=0
  > Feb 25 16:50:45 squeezeplay: DEBUG  audio.decode - 
decode_pause_audio_handler:171 pause_audio decode state: 1 audio state 2
  > Feb 25 16:50:45 squeezeplay: DEBUG  audio.decode - 
decode_pause_audio_handler:156 decode_pause_handler interval=0
  > Feb 25 16:50:45 squeezeplay: DEBUG  audio.decode - 
decode_pause_audio_handler:171 pause_audio decode state: 1 audio state 2
  > Feb 25 16:50:45 squeezeplay: DEBUG  audio.decode - Playback.lua:1262 
stopping local pause timer
  > 
  > After a few minutes of good playback, again suddenly “POP”:
  > 
  > Feb 25 16:54:48 squeezeplay: INFO   audio.decode - Playback.lua:448 
100.0%/91.5%
  > Feb 25 16:54:49 squeezeplay: INFO   audio.decode - Playback.lua:448 
100.0%/90.7%
  > Feb 25 16:54:50 squeezeplay: INFO   audio.decode - Playback.lua:448 
99.9%/90.6%
  > Feb 25 16:54:51 squeezeplay: INFO   audio.decode - Playback.lua:448 
99.9%/91.3%
  > Feb 25 16:54:52 squeezeplay: INFO   audio.decode - Playback.lua:448 
100.0%/94.6%
  > Feb 25 16:54:53 squeezeplay: INFO   audio.decode - Playback.lua:448 
100.0%/97.8%
  > Feb 25 16:54:54 squeezeplay: INFO   audio.decode - Playback.lua:448 
100.0%/99.3%
  > Feb 25 16:54:55 squeezeplay: INFO   audio.decode - Playback.lua:448 
100.0%/99.3%
  > Feb 25 16:54:55 squeezeplay: playback_callback:346 Audio underrun: used 53 
frames, requested 441 frames. elapsed samples 24695419
  > Feb 25 16:54:56 squeezeplay: INFO   audio.decode - Playback.lua:364 OUTPUT 
UNDERRUN
  > Feb 25 16:54:56 squeezeplay: DEBUG  audio.decode - decode_pause_audio:624 
decode_pause_audio interval_ms=0
  > 
--------------------
> > 
> 
> 
> I'm not familiar with this at all. I really don't know what the
> motivation is. :)
> 
> I would note that the Radio, when playing through speakers, does its
> own "downmix" in the crossover/dsp component. I can pull out the logic
> that it applies, it might be worth checking to ensure that
> inconsistencies are not introduced.
> 
> 
> I will have a look at these, it might be educational ! If (unlikely) I
> have anything useful to say, I shall revert.

Thank you for testing this.  Looks like we cross posted.  I found
setting the outputThreshold to 20 gives a quicker startup and still
prevents the underrun.  Need to do more testing with that server side
change with all the aac content that played fine before changing it.

Hence my comments about no real need for the downmix feature for the
radio.  I couldn't hear any difference between the bass driver and
tweeter with it set to stereo or mono output channel mode.  But if I add
it to the community firmware I didn't want the change to be in one and
not the others, just too confusing.

Other than those 2 patches, the difference between the previous test
static jive and the stutterfix jive is the stutterfix does NOT have
fdk-aac linked static, which is the same as the jive binary included in
r18635.
I haven't seen/heard the "POP" issue with any of the 3 jive binaries. 
Very strange.



Ralphy

*1*-Touch, *5*-Classics, *3*-Booms, *2*-UE Radio
'Squeezebox client builds'
(https://sourceforge.net/projects/lmsclients/files/) 'donations'
(https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=LL5P6365KQEXN&lc=CA&item_name=Squeezebox%20client%20builds&currency_code=USD&bn=PP%2dDonationsBF%3abtn_donate_SM%2egif%3aNonHosted)
always appreciated.
------------------------------------------------------------------------
ralphy's Profile: http://forums.slimdevices.com/member.php?userid=3484
View this thread: http://forums.slimdevices.com/showthread.php?t=113479

_______________________________________________
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Reply via email to