I've realised that I was also talking nonsense about the buffer being allocated more than once. I looked at the code, properly this time:

This time I noticed the static declaration and the check for NULL before allocating

So I was wrong about most of what I said, but I still stand by my claim that increasing the buffer size would have no effect

I've just realised that those of us with Squeezebox Controllers (I'm looking at you Rod) no longer really have a need for much of the functionality in slimrio. All that we need is a copy of the original slimp3slave player run from the init script.

I might have a play with that, I guess I would have to rip out slimp3slave's curses UI to get it to build.

Sorry for my long absence from this thread. It's taken me a while to catch up and properly investigate the audio-stuttering problem. I am now sure that the trouble is that madplay/libmad can't keep up with decoding in real-time, as can be demonstrated by running it directly from the command line on a suitable file---the CPU is flat out and audio still sometimes breaks up. By comparison, the CPU is very lightly loaded by the original Rio application. Maybe they were using an exceptionally efficient mp3 decoder, but it seems possible there is something wrong with my build of libmad. Unfortunately, I've since messed up the toolchain I used (trying to swap from scratchbox to sb2 and back) and I'm currently having difficulty building anything at all.

In the meantime, I suggest those who can't live with limiting the mp3 bit-rate try this
kludged version 0.7b

I hope to have better results to report soon.

I am pleased to report that apart from one stutter the first time that I changed the volume that it appears to be stutter free !

Well done that man. What did you change in 0.7b ?

0.7b seems very good for me. Decoding a 320kbps VBR? mp3 (as reported by squeezecenter) without downsampling and without clitches!

uptime on the rio reports values ranging from 1.10 to 1.63 throughout the file.


Thanks! It's working great!

It seems to be working great for me too

Brilliant, Many Thanks!

Cheers

Cris.

Now that we have stuttering sorted I do have another issue to report that I hadn't bothered reporting until now.

Whenever I start playing something I get a click or thump (much like the sound when plugging/unplugging something into an amplifier that is turned on). It only happens however in when it is a user commanded action and also doesn't happen on pause/unpause:

start a new track or playlist: clicks
move to the next track in the playlist using next track: clicks
allow the next track to play after the current one finishes: no clicks
pause: no click
unpause: no click
stop (hold pause on Squeezecenter Controller): no click
restart from stop (press pause): clicks

Sometimes there is a single click, other times there are two clicks, can't work out the pattern of when there is just one click.

The clicks happen no matter how I control the player (front panel controls, Squeezebox Controller, SqueezeCenter).

I'm not getting any clicking ???

I've had it on all afternoon on Random and it has been flawless the whole time on 0.7

Have you got another unit to try it with?

Cheers

Cris.

If you had it on random all the time and didn't skip tracks then you wouldn't get any clicks (except one when you started the first track).


I have a number, I'll just go and raid the box in the loft

I tried another unit, a Rio Receiver, which shows exactly the same symptoms. Eryl confirms that there is indeed a click, so I'm not making it up, it is extremely noticeable.

I was going to try a Dell unit as well, but I can't get those to boot, I guess I need the newer version of the ARM software.

My Dells definitely click as well, so that is four units all the same.

Hmmm, I tried it skipping tracks etc... and can't hear a click, I even tried some tracks with a very quiet start.

What version of Slimserver are you running? I guess it will be 7, I am still on 6.something

Cheers

Cris.

If it was clicking you would hear it very clearly. I am on 7.01, but it was clicking on 7.0 as well.

I don't know if it happened on 6.5 as well, I was more concerned about the stuttering at that point. I'll see if I can remember to install 6.5 on a virtual machine somewhere tomorrow and see if that makes a difference.

Doing a quick diff of 6.5 and 7.01 there appear to be a lot of differences in the server side code for Slimp3, especially around buffering and syncing. Anyone else using 7 getting clicks ?

I'm using version 7 (and used 6.5x prior to 7) and not noticing any clicks at the beginning of tracks after a start or a skip. I have both Dell and Rio units. I use RCA outputs on all my receivers.

Me too, I don't use the integrated amp, I can dig out some old speakers to test if needed Andy.

Cheers

Cris.

I get clicks on both the RCAs and the speaker outputs (tested that last night as I realised I had only tested the RCAs until then).

2 x Dell's working fine now, feel slightly cheated that I don't have the free clicks though.

Fantastic! Since Paul's tRio project stalled I had been searching for an alternative to the stock software, but SlimRio's audio glitches were too annoying. Now, however, I am happy!

BTW, does anybody else miss the predictive text search abilities of the standard software? Being able to find a track by title, album or artist by pressing just a few buttons is a great feature that I miss.

Many thanks for all the hard work that's gone in to getting this to work.
Mark

Try this http://www.hickinbottom.com/lazysearch

Thanks Andy. I'll give it a whirl

Do you happen to know what happened to Paul N? It's a pity tRio has died, since it was developing nicely (and used the screen on the receiver properly!)

Mark

Thanks for this update! After using this version, I no longer have problems with skipping audio. As a bonus, syncing now works great! Can't say if this update would have done anything to fix syncing directly, or if it was the added load on the server having to manage the down-converting to 128 and syncing at the same time... Anyway, I've now got Sync working on 2 Receivers + SoftSqueeze + Squeezebox3. Of course, all the players don't start each track at exactly the same time, but within a few seconds all are playing correctly synced.

I'm clearly not having much luck with this then. As well as my problems of clicking when I start/skip a track I also have huge problems with syncing. I can't get two Rio Receivers to sync, let alone syncing with anything else.

Andy,
Many thanks for the LazySearch link. It does just what I needed.

Regarding the "kludged version" of SLimRio, I tried the other fixes (downsampling, scrolling etc.) but had no luck. However the kludge has fixed my skipping problems, but I can no longer sync!

Andy and bmark,
Have you verified that syncing doesn't fix itself a few seconds into the track? Maybe even midway through the track? SC makes constant changes based on the buffer levels of all the various players.

Come to think of it, what is the memory buffer size in SlimRio? Does it report correctly to SC?

I did play around with the audio delay and start delay settings in SC, but I don't know if the audio delay values are device dependent or network dependent. One Receiver has 1000ms (over ethernet) and the other 250ms (over wifi).

I'm back to getting "Short Packet" messages on Dell display and drop outs in playback.

Odd how it worked for a while

I was certainly playing with player settings to try getting mine to sync, but cannot think why that would have messed up the playback.

Sometimes the Receivers start in sync and then drift off, sometimes they start out out of sync and drift off further. At no time do they stay in sync or get any closer in sync during a track

Robin appears to have simplified the buffer handling in the code that he took from the original slimp3slave. In particular his code doesn't seem to have the functionality that requests missing packets. That may explain why some of us have had what appear to be missing data issues.

It would be good to know what tweak he made to the latest 0.7 that fixed some of the buffering issues.

Given my last effort at parsing the slimrio code that should probably all be taken with a huge pinch of salt though.

Since the ethernet on the Receiver is so flaky, maybe you could try plugging it into a different port. Maybe it's having collision issues due to bad autonegotiation.

My two Dells are both on different switches already, one on a Cisco the other on a Dell switch. But tried other ports same results, both are dropping packets.