AlienBBC on NSLU2

**bpa** · 2006-08-04, 15:00

To see if any output is coming from lame to slimserver try d_source_v.

It is possible that NSLU2 hasn't enough CPU or memory for the processes required i.e. slimserver, mplayer, shell, lame

IIRC Linkstation II with a mipsel 200MHz processor get choppy audio.

Have you verified that mplayer runs standalone and output sent to a file in WAV format is OK. If so then try piping mplayer output into lame to get an MP3 file.

**Andrew** · 2006-08-04, 16:13

Hi,

Well I was afraid it might not have enough oomph but thought I would give it a go.

At least if I don't get it going I can post and save others the trouble of trying.

I don't have lame installed, I was trying to avoid another process is the chain. Shouldn't it be possible to run using wavs?

thanks,

-- Andrew

**bpa** · 2006-08-04, 16:36

WAV should be ok - when using mplayer pre8 there is also a possibility of not using mplayer.sh and /dev/fd through IO redirection.

I'm curious to know whether NAS type devices are CPU or memory bound. I have been playing around how to minimise the size of mplayer but if the NAS is CPU bound there is little point.

**Andrew** · 2006-08-04, 17:33

Hi,

Thanks for the latest info on the logging commands.

I get lots and lots of these....

2006-08-04 17:27:52.2832 would have blocked, will try again later
2006-08-04 17:27:52.3210 would have blocked, will try again later
2006-08-04 17:27:52.3736 would have blocked, will try again later
2006-08-04 17:27:52.4336 would have blocked, will try again later

I suspect you are right and the NSLU2 doesn't have enough horsepower hence the blocking IO.

Does that seem a logical deduction?

The memory appears OK on the NSLU2, but 'top' seems to imply that CPU is max'ed out.

I suppose I could open it up and remove the pulldown resistor that causes the CPU to clock at half speed.....

cheers,

-- Andrew

**bpa** · 2006-08-04, 18:00

"would have blocked" is Slimserver waiting for a block of data to be read from mplayer. It is possible that there is some other problem - you should check what "top" says about standalone mplayer - if necessary send WAV output to /dev/null.

It is probably CPU if the CPU is not wasting time swapping.

**Andrew** · 2006-08-04, 18:12

Hi again,

Did this....

/usr/local/bin/mplayer -bandwidth 10000000 -cache 128 -playlist http://www.bbc.co.uk/radio/aod/shows...paul_jones.rpm -vc null -vo null -ao pcm:nowaveheader:file=/dev/null -af volume=1,resample=44100:0:1,channels=2

"top" says CPU 96%

Looks like one CPU bound NAS :-( Looks like you have your answer.

Time to get a bigger box...I might still try removing the resistor....

thanks again,

-- Andrew

**bpa** · 2006-08-04, 21:23

That test might not be realistic as the "bandwidth" option makes BBC server deliver data as fast as it can be processed and dumping to /dev/null will consume data as fast as it can be written so Mplayer will use as much CPU as it can as there it nothing to throttle it. Usually audio playback slows down output.

Retry the test without "bandwidth" option and on a live stream - this can only deliver data at real time speed.

**Andrew** · 2006-08-04, 22:38

Hi,

I tried as you suggested, CPU is constantly maxed out at 98%.

I also desoldered the pulldown resistor on R83, which makes the standard NSLU2 run at half clock speed. So I now have a turbo SLUG. So unless I have a configuration error I think I need more oomph!

CPU: ARM

STREAM_HTTP(1), URL: http://www.bbc.co.uk/radio/aod/shows...paul_jones.rpm
Resolving www.bbc.co.uk for AF_INET...
Connecting to server www.bbc.co.uk[212.58.224.55]: 80...
Cache size set to 128 KBytes
Linux RTC init error in ioctl (rtc_irqp_set 1024): Invalid argument
Try adding "echo 1024 > /proc/sys/dev/rtc/max-user-freq" to your system startup scripts.

Playing rtsp://rmv8.bbc.net.uk/radio2/paul_jones.ra.
STREAM_RTSP, URL: rtsp://rmv8.bbc.net.uk/radio2/paul_jones.ra
Resolving rmv8.bbc.net.uk for AF_INET...
Connecting to server rmv8.bbc.net.uk[212.58.224.64]: 554...
Cache size set to 128 KBytes
Cache fill: 18.75% (24576 bytes)
REAL file format detected.
Stream description: audio/x-pn-multirate-realaudio logical stream
Stream mimetype: audio/x-pn-realaudio
Clip info:
name: Paul Jones
author: BBC Radio 2
copyright: (C) British Broadcasting Corporation 2006
================================================== ========================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, s16be, 32.0 kbit/2.27% (ratio: 4005->176400)
Selected audio codec: [ffcook] afm: ffmpeg (FFmpeg COOK audio decoder)
================================================== ========================
[AO PCM] File: /dev/null (RAW PCM)
PCM: Samplerate: 44100Hz Channels: Stereo Format s16le
[AO PCM] Info: Faster dumping is achieved with -vc null -vo null -ao pcm:fast
[AO PCM] Info: To write WAVE files use -ao pcm:waveheader (default).
AO: [pcm] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 19.3 (19.3) of 3481.0 (58:01.0) 1032.1% 34%

Any suggestions welcome...desparation is now setting in...

cheers,

-- Andrew

**Andrew** · 2006-08-04, 22:57

Whoops getting tired, did a "listen again" I'll try a live stream.....doh!

-- Andrew

**bpa** · 2006-08-04, 23:37

I'm not sure of the processing power of the ARM in the NSLU2 - it is 133MHZ shipped and 266MHz modded.

Linkstation HG (266MHZ ppc) can handle AlienBBC OK but I think it was with RealAudio libraries (i.e. probably assembly & optimised) and not the inbuilt ("C" - not very optimised) decoder.

Other uses have tried Linkstation-II HD (400MHz MIPSel ) with inbuilt Mplayer RealAudio decoder and got choppy audio.

Some users of the Zaurus PDA have used a version of Mplayer to play video - I think the processor is 206MHz StrongARM.

My gut feel is the Mplayer RealAudio codec (ffcook) is generic C code and not optimised and so usable by any processor architecture.

**Andrew** · 2006-08-04, 23:37

Tried a live stream, no joy, still 98%......I suppose the CPU only has to be 1% OTT for the stream to start to drop.

cheers,

-- Andrew

**bpa** · 2006-08-07, 08:43

I just a test on a Kuro box which has a 266MHZ PPC & 128Mbytes RAM with minimal processes running.

I ran your PaulJones test with pre8 mplayer inbuilt Real codec, output to /dev/null

With bandwidth option - 98% CPU
Without bandwidth - 7-10% CPU

So if you are sure about your test with no bandwidth option - then there must be some difference between PPC and ARM processors (e.g. floating point) to make such a big difference.

**Andrew** · 2006-08-09, 11:00

Hi,

Let me check again, tonight, with a fresh head ;-) Can you post the exact command you used? In the interest of make sure we both do the same thing.....

cheers,

-- Andrew

**bpa** · 2006-08-09, 11:51

The command I used was the one you posted - I copied and pasted into the console window of the Kuro box.

In terms of processor the PPC used in the Linkstation HG/Kuro-HG has a floating point unit and PPC was considered a powerful processor so MHz is not necessarily a good comparison.

The ARM processor used in NSLU2 has a more limited instruction set so perhaps the Mplayer code needs to be examined. I did a quick check and there is minimal floating point but fair amount of fixed point division which may be the culprit. However without code profiling I don't know what code is excuted most.

If you repeat your results - I'll post something onto the Mplayer developers' list to see if they have any ideas.

AlienBBC on NSLU2

AlienBBC on NSLU2

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment