PDA

View Full Version : AACPlus fails with 6.5.0



Ramage
2006-09-28, 01:36
I'm using 6.5.0 on win XP, which plays AACplus streams OK with no bitrate limit set. When a bitrate limit is set for a player, either SB3 or Softsqueeze 3, I get the message "Problem: Can't connect to server".

I have switched out the firewall and ensured that all the slim applications are included in the permitted programs list of the firewall. This effect seems related to the use of lame to transcode to mp3.

I have double checked the entries in "custom-convert.conf" and they are as per bpa's wiki entry.

Edit: Bitrate setting works with other formats such as wma and mp3.

6.3.1 worked OK with and without the bitrate limit set.

Can anyone help with further diagnosis?

bpa
2006-09-28, 01:43
Lame has to be installed for bit rate limit to work.

If lame is installed - post a log with d_source enabled.

Ramage
2006-09-28, 01:58
Thanks for quick response. Lame is installed and working OK (see the edit on my first post).

The log using d_source attached.

bpa
2006-09-28, 02:39
Look likes a slimserver problem - I need to investigate further.

Can you confirm bit rate works OK with MP3 streams which provide song titles and not just MP3 files ?

Ramage
2006-09-28, 02:53
Had to do a number of tests to confirm, but mp3 streams which display song titles when no bit rate limit, only display the long Station ID when bitrate limit is active, and no song titles.

This observation could not be repeated in later tests.

Ramage
2006-09-28, 06:24
I checked some mp3 and AAC+ streams on my linux 6.3.1 box and found similar but not identical problems, may throw some more light on the problem or not.

128K CBR MP3 streams containing song info produce white noise bursts when bit rate is set lower that the stream rate e.g 96K.

AAC+ streams at 32K CBR convert to 96K ABR and run correctly.

bpa
2006-09-28, 07:15
That's good because AACplus is essentially a MP3 with a different decoder - so the problem is not just my aacplus solution.

What streams did you use to test ?
I'll try to get around to this later.

Ramage
2006-09-28, 08:13
Some of the streams tested on linux slimserver v 6.3.1:

http://69.5.81.70:7050 :Boot Liquor: mp3 128K conv to 96K = noise. Song titles streamed.

http://130.166.72.1:8006 :Classic Heartland: mp3 128K conv to 96K = noise. Song Titles streamed.

http://72.236.125.114:8020 :Rooster Radio: AAC+ 32K conv to 96K = OK. Song titles streamed.

http://mp3media1.abc.net.au:8060/digcountry.mp3 :DigCountry: mp3 128K conv to 96K = OK. Song titles not streamed.

http://202.6.74.107:8060/digjazz.mp3 :Dig Jazz: mp3 128K conv to 96K = OK. Song titles not streamed.

Ramage
2006-09-28, 08:39
Streams tested on WinXP slimserver v 6.5.0:

http://69.5.81.70:7050 :Boot Liquor: mp3 128K conv to 96K = OK. Song titles streamed.

http://130.166.72.1:8006 :Classic Heartland: mp3 128K conv to 96K = OK. Song Titles streamed.

http://72.236.125.114:8020 :Rooster Radio: AAC+ 32K conv to 96K = Can't Connect.

http://160.79.128.40:7016 :Sky Country: AAC+ 24K conv to 96K = Can't connect.

These checks seem to contradict my previous post #5, and I can't repeat those observations. All mp3 streaming titles tested OK.

bpa
2006-09-29, 02:00
A status report as I wont be able to get back to this for a while

1. I think caching interferes with what is happening when changes are made - so sometimes a change is made but the cached value overrides the change. I found to get reproducible test results - clear database and cache between changes & runs.

2. In 6.5 more use of direct streams was made - whereby the SB talks to the source directly. The confusion seems to be AACplus looks like an MP3 direct stream. Without bit rate limit SS identifies it as a special format and processes correctly. With bit rate it sees the end result as MP3 so it tries to direct stream to SB - but just as SS starts the direct stream SS finds the stream is in AACPlus format and can't be handled directly by SB so it stops. Use d_directstream, d_source and d_remotestream to get an idea of what is happening.

3. I think bit rate limiting doesn't work for MP3 streams - when I enable a limit of 64k on a 96k stream - no lame process is set up and the 64 is ignored. The stream plays OK but it is not bit rate limited. This may be true of all direct stream formats - point 4 could test this.

4. I'd like to test bit rate limit on WMA but prefer to keep my SB on a 6.3.1 NAS so if you could test this it would be helpful. Check for a lame process when stream it running.

Ramage
2006-09-29, 02:43
Thanks for the update. I'll run some tests as you suggest and let you know the results.

Ramage
2006-09-29, 06:46
Music files

File mp3 128K converted to 64K as displayed on SB3 screen. Lame launches at start of track at 90% - 99% CPU usage, and stops after 45-60 secs . When lame stops, network traffic reduces to background level from 500K, indicating that the track has been loaded into SB3 buffer. Slimserver can be stopped at this point and the track will continue to play to its end.

File wma 97K converted to 64K as displayed on SB3 screen. Lame and wmadec launch at start of track and both drop after 45-60 sec when network traffic drops from around 500K to background (9K6) as per above observation.

The indicated network rate of 500K at start of track implies that bitrate limit is not actually happening.

Internet Radio Streams

mp3 128K converted to 64K as displayed on SB3 screen. No evidence of lame being launched at stream start; therefore conclude that the bitrate conversion is not happening. Because of buffering, it is impossible to measure the actual server output bit rate. Debug log indicates that although conversion is attempted it gives up and goes to direct mode.

aac+ 32K will not run when bitrate limit set. No evidence of lame starting.

wma 128K converted to 64K as displayed on SB3 screen. Lame and wmadec launched. Buffering took a long time (2mins) and when eventually loaded, the output was white noise. CPU usage 100%. Debug log attached

wma 128K No limit SB3 built-in wma deselected. Network rate 1.5Mb/s - output OK.

wma 128K converted to 320K as displayed on SB3 screen - SB3 built-in wma deselected. Lame and wmadec running output OK. Network rate limited to 320K. Working as it should but CPU usage is 100% - mainly lame.

Conclude that an indication of conversion on the SB3 screen does not reflect the reality of any conversion or limit.

The player connects directly to internet streams on any built-in protocol, and once a stream is playing, slimserver can be stopped and the music will continue for as long as the stream stays up - the information on the SB3 display is of course lost.

Debugging.

Debugging logs using d_directstream and d_source for mp3 and wma streams are attached.

raff
2006-12-13, 04:03
sorry to bump this conversation but has anyone managed to solve this issue?
I'm also trying to stream aacplus radio station but because I'm using remote slimserver I'm forced to use bitrate limiting.
While I generally do not have problems with any other formats aacplus fails as soon as you switch bitrate limiting on.

Slimserver should use custom-convert.conf entry for aap->mp3 but instead it thinks it can decode aacplus stream directly and fails miserably.

help anyone?

bpa
2006-12-13, 04:20
Nothing has been done. There is a bit of uncertainty but if there is any resolution from the developers it will not be until 7.0. Officially it was not intended that streams be capable of being bit rate limited so AFAICT the functionality of bit rate limiting aacplus in 6.3 was fortuitous.

You should check whether the stream in question also provides an MP3 stream - most aacplus station also provide a lower quality mp3.

I may look at the code in more detail to see what is happening but to be honest getting aacplus was all I needed.

raff
2006-12-13, 09:39
well I got it sorted ;)

took advice from Bryan http://bugs.slimdevices.com/show_bug.cgi?id=4266



In the sub canDirectStream in file /Slim/Player/Protocols/HTTP.pm - line 189
if (defined $command && $command eq '-' || $format eq 'mp3') {

The "|| $format eq 'mp3'" seems to overide any bitrate conversion and makes sure direct streaming happens.


As soon as I changed this sub by removing "|| $format eq 'mp3'" (actually I added additional 'if' statement inside this original 'if' to check for 'aap' and 'mp3') - aacplus started working as it should with or without bitrate limiting. I'm not sure if this will have some side effects but for now I'm one happy guy ;) at long last I can stream my favorite radio from my dedicated web server (kind of customised/private SqueezeNetwork) wherever I am - office or home.

best regards
raff

bpa
2006-12-13, 09:57
That is my patch - there are some side effects but I can't remember the details. Maybe your addition gets rid of the effects.

raff
2006-12-13, 10:43
Full credit to you then ;) ... I didn't realise that Bryan and bpa is the same person - my apologies.
Anyhow I don't really understand the reasoning of developers. If such facility is available why removing it? In the end it makes the server software so much more versatile.

Ramage
2006-12-14, 01:02
well I got it sorted ;)

took advice from Bryan http://bugs.slimdevices.com/show_bug.cgi?id=4266



As soon as I changed this sub by removing "|| $format eq 'mp3'" (actually I added additional 'if' statement inside this original 'if' to check for 'aap' and 'mp3') - aacplus started working as it should with or without bitrate limiting. I'm not sure if this will have some side effects but for now I'm one happy guy ;) at long last I can stream my favorite radio from my dedicated web server (kind of customised/private SqueezeNetwork) wherever I am - office or home.

best regards
raff

Raff

Could you post the details of your modified bpa patch on here, my PERL skills are very limited?

raff
2006-12-14, 15:43
I simply added additional check for $type of the stream (aap) and $format (mp3)
It is not perfect - it's too 'specific' for 'universality' of the code but it works for me ;)
In fact I agree with Bryan - this check on "$format eq 'mp3'" shouldn't be there at all but since it is, it might have some other purpose which I'm not aware of...

This patch should not affect other parts of the code but should enable you to do bitrate limiting on AACPlus streams.

Have a look at "/usr/local/slimserver/Slim/Player/Protocols/HTTP.pm" starting at line 189.

then change this:




if (defined $command && $command eq '-' || $format eq 'mp3') {
return $url;
}


to this:



if (defined $command && $command eq '-' || $format eq 'mp3') {
if ($type eq 'aap' && $format eq 'mp3') {
return 0;
} else {
return $url;
}
}


HTH
raff

Ramage
2006-12-15, 02:28
I simply added additional check for $type of the stream (aap) and $format (mp3)
It is not perfect - it's too 'specific' for 'universality' of the code but it works for me ;)
In fact I agree with Bryan - this check on "$format eq 'mp3'" shouldn't be there at all but since it is, it might have some other purpose which I'm not aware of...

This patch should not affect other parts of the code but should enable you to do bitrate limiting on AACPlus streams.

Have a look at "/usr/local/slimserver/Slim/Player/Protocols/HTTP.pm" starting at line 189.

then change this:




if (defined $command && $command eq '-' || $format eq 'mp3') {
return $url;
}


to this:



if (defined $command && $command eq '-' || $format eq 'mp3') {
if ($type eq 'aap' && $format eq 'mp3') {
return 0;
} else {
return $url;
}
}


HTH
raff

Thanks Raff