expectingtofly wrote: 
> To Complete the analysis,  I've added a setting to BBC Sounds that an
> interval can be set between fetching audio chunks from the BBC,
> effectively applying a throttle to the amount of data that can be made
> available to the radio.
> 
> Here is a log where I have specified at least 2 seconds occurs before
> the next 6 second chunk of audio is fetched from the BBC (on
> Audio-on-demand content).
> It solves the problem, as the radio has time to decode, rather than
> filling up the input buffer.  No underrun occurs.   Effectively,
> prioritising decoding over input buffering.
> 
> > 
Code:
--------------------
  >   > 
  > Mar  1 11:54:07 squeezeplay: INFO   audio.decode - Playback.lua:477 connect 
172.16.0.8:9000 GET /stream.mp3?player=00:04:20:2c:fa:10 HTTP/1.0^M
  > Mar  1 11:54:07 squeezeplay: DEBUG  audio.decode - Playback.lua:194 
source=stream
  > Mar  1 11:54:07 squeezeplay: DEBUG  audio.decode - stream_connectL:506 
streambuf connect 172.16.0.8:9000
  > Mar  1 11:54:07 squeezeplay: DEBUG  audio.decode - Playback.lua:1262 
stopping local pause timer
  > Mar  1 11:54:07 squeezeplay: DEBUG  audio.decode - Playback.lua:1192 gainL, 
gainR: 1098 1098
  > Mar  1 11:54:08 squeezeplay: DEBUG  audio.decode - Playback.lua:397 resume 
decoder, 63712 bytes buffered, decode threshold 2048
  > Mar  1 11:54:08 squeezeplay: DEBUG  audio.decode - 
decode_resume_decoder:580 decode_resume_decoder
  > Mar  1 11:54:08 squeezeplay: DEBUG  audio.decode - 
decode_resume_decoder_handler:122 resume_decoder decode state: 1 audio state 0
  > Mar  1 11:54:08 squeezeplay: DEBUG  audio.decode - debug_fullness:112 
fullness: 63712 / 0 | 2.03% / 0.00%
  > Mar  1 11:54:08 squeezeplay: DEBUG  audio.decode - 
decode_output_samples:280 first buffer sample_rate=48000
  > Mar  1 11:54:08 squeezeplay: INFO   audio.decode - Playback.lua:448 
3.7%/0.5%
  > Mar  1 11:54:08 squeezeplay: DEBUG  audio.decode - Playback.lua:424 resume 
audio bytesReceivedL=190976 outputTime=234 threshold=122880
  > Mar  1 11:54:08 squeezeplay: DEBUG  audio.decode - decode_resume_audio:601 
decode_resume_audio start_jiffies=0
  > Mar  1 11:54:08 squeezeplay: DEBUG  audio.decode - 
decode_resume_audio_handler:133 decode_resume_audio_handler start_jiffies=0
  > Mar  1 11:54:08 squeezeplay: DEBUG  audio.decode - debug_fullness:112 
fullness: 145920 / 106496 | 4.64% / 3.02%
  > Mar  1 11:54:08 squeezeplay: DEBUG  audio.decode - 
decode_resume_audio_handler:146 resume_audio decode state: 1 audio state 40
  > Mar  1 11:54:08 squeezeplay: DEBUG  audio.decode - Playback.lua:381 status 
TRACK STARTED (elapsed: 112)
  > Mar  1 11:54:09 squeezeplay: INFO   audio.decode - Playback.lua:448 
6.7%/6.4%
  > Mar  1 11:54:10 squeezeplay: INFO   audio.decode - Playback.lua:448 
11.3%/8.7%
  > Mar  1 11:54:11 squeezeplay: INFO   audio.decode - Playback.lua:448 
13.7%/10.7%
  > Mar  1 11:54:13 squeezeplay: INFO   audio.decode - Playback.lua:448 
16.2%/14.5%
  > Mar  1 11:54:14 squeezeplay: INFO   audio.decode - Playback.lua:448 
18.8%/15.2%
  > Mar  1 11:54:15 squeezeplay: INFO   audio.decode - Playback.lua:448 
21.2%/18.5%
  > Mar  1 11:54:16 squeezeplay: INFO   audio.decode - Playback.lua:448 
25.9%/18.9%
  > Mar  1 11:54:17 squeezeplay: INFO   audio.decode - Playback.lua:448 
26.0%/24.4%
  > Mar  1 11:54:18 squeezeplay: INFO   audio.decode - Playback.lua:448 
32.8%/24.7%
  > Mar  1 11:54:19 squeezeplay: INFO   audio.decode - Playback.lua:448 
30.7%/29.3%
  > Mar  1 11:54:20 squeezeplay: INFO   audio.decode - Playback.lua:448 
37.5%/30.6%
  > Mar  1 11:54:21 squeezeplay: INFO   audio.decode - Playback.lua:448 
34.9%/40.6%
  > Mar  1 11:54:22 squeezeplay: INFO   audio.decode - Playback.lua:448 
41.3%/45.3%
  > Mar  1 11:54:23 squeezeplay: INFO   audio.decode - Playback.lua:448 
39.6%/48.0%
  > Mar  1 11:54:24 squeezeplay: INFO   audio.decode - Playback.lua:448 
46.4%/48.6%
  > Mar  1 11:54:25 squeezeplay: INFO   audio.decode - Playback.lua:448 
46.8%/50.8%
  > Mar  1 11:54:29 squeezeplay: INFO   audio.decode - Playback.lua:448 
42.6%/98.9%
  > Mar  1 11:54:29 squeezeplay: WARN   net.thread - NetworkThread.lua:146 
network thread timeout for Task(SocketHttp {piCorePlayer_Request}(R))
  > Mar  1 11:54:30 squeezeplay: INFO   audio.decode - Playback.lua:448 
51.6%/97.3%
  > Mar  1 11:54:31 squeezeplay: INFO   audio.decode - Playback.lua:448 
56.4%/98.1%
  > Mar  1 11:54:32 squeezeplay: INFO   audio.decode - Playback.lua:448 
56.5%/97.8%
  > Mar  1 11:54:33 dropbear[2293]: Child connection from 172.16.0.70:40578
  > Mar  1 11:54:33 squeezeplay: INFO   audio.decode - Playback.lua:448 
62.0%/95.2%
  > Mar  1 11:54:34 squeezeplay: INFO   audio.decode - Playback.lua:448 
63.1%/92.5%
  > Mar  1 11:54:35 squeezeplay: INFO   audio.decode - Playback.lua:448 
67.7%/93.2%
  > Mar  1 11:54:37 squeezeplay: INFO   audio.decode - Playback.lua:448 
72.5%/93.3%
  > Mar  1 11:54:37 dropbear[2293]: Password auth succeeded for 'root' from 
172.16.0.70:40578
  > 
--------------------
> > 
> 
> Actually, I'm probably happy to release like this, with a default of 1
> second interval throttling,  you could probably argue that does have
> benefits server side. 
> Obviously, this is very BBC Sounds specific.     What's your thoughts?

I think that's a good solution.  I was replying to your previous
regarding outputThreshold when I spotted these.

Basically, there are 2 threshold values sent from the server in the strm
command.
1. $threshold - the KB of input buffer data before autostart or notify.
2. $output_Threshold - amount of output buffer data before playback
starts, in tenths of a second.
and the player honours/ignores 1. depending on the auto start flag.

I've been investigating how the aac decoder implemented in the community
firmware on the radio responses to the thresholds and under what
conditions they are applied, but that's going to take some time.

expectingtofly wrote: 
> Further to the above, I've tested applying the throttling to the r16835
> release of the firmware.   I can confirm it also eliminates the buffer
> underrruns for that release.

That's great!  Even with the bug in r16835 that reports that the number
of decoded samples is only 1/4 of what's actually available, the
throttle is enough to let the radio recover.



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