Ok I thought it would make sense to break this out into a separate thread.

I have done the test I promised and also listened to the drop outs more carefully.

Firstly, I can rule out anything to do with my wireless LAN, the problem doesn't go away when I move my Rio to the hub the my DSL connection comes into.

Secondly, on listening to the drop outs more carefully it sounds line no audio is actually being lost, it just pauses for a fraction of a second. The time counter on the display also appear to pause when a drop out occurs.

P.S. It could be that it really is losing some audio, it just sounds like it is only pausing (my wife agreed that it sounded like it was pausing), because I can't see how it can keep pausing every few seconds, given that it is a live stream we are talking about.

Diagnostic questions:

- These same streams do not pause when you are listening to them in WinAmp on the PC? In other words, you're sure it's the Receiver's fault and not just a crappy internet server or a crappy internet connection?

- Does it happen all the time or just once in a while? In other words, can you reproduce it reliably?

- Do regular MP3s play back OK on the Receiver, in other words, are you sure this problem is only with the streams from the 'net?

Good questions as ever Tony...

These same streams do not pause when you are listening to them in WinAmp on the PC? In other words, you're sure it's the Receiver's fault and not just a crappy internet server or a crappy internet connection?

Correct, they all play back fine in WinAmp (including the stream that is sourced locally from my digital radio tuner).

Does it happen all the time or just once in a while? In other words, can you reproduce it reliably?

Yes is can be repro'd 100%. It varies though, with the pauses coming every 2-20 seconds apart, the gaps between pauses seem fairly random. The pauses happen on every stream I have tried.

Do regular MP3s play back OK on the Receiver, in other words, are you sure this problem is only with the streams from the 'net?

Yes, everything but streams play fine. In fact if I take my MP2 stream from my tuner, capture it to disk, change the extension to MP3, import it into the Receiver manager then it plays fine (if a little slow as it is a 48khz stream).

Are there really only two people that this problem occurs with ?

It couldn't be anything as silly as 50Hz mains power vs. 60Hz could it (I'm in the UK on 50Hz). Sounds unlikely I know ;-)

This is possibly due to too small of an input buffer in Rioplay. It's only 50000 bytes right now. I'll try increasing that. On the other hand, it doesn't seem like the buffer should be that big of an issue when using your local MP2 stream...

Dave, I've been studying the code a bit. My guess is that 50,000 bytes of buffer should be enough.

It seems that the path through the AudioThread::InputCallBack code is different when being served from a shoutcast stream vs. from the Rio HTTP server. This might be worth some additional study.

Specifically, there is this business with the MetadataFrequency.

Here are some questions wrt AudioThread::InputCallBack
1) There are these weird for loops to read in stuff related to metadata. Could you explain what you are doing there. I just couldn't understand why you can't simply do a single fread(). Though, I am sure you have a reason for this.

2) Shouldn't you grab the ClassMutex before calling Display.Update for the metadata? You seem to do that in the OutputCallback code. Or is that lock used to protect something else?

Hope this helps. I am going to take a look at some other code that parses shoutcast streams to understand what they are doing vs. what you are doing.

Cheers,
Marc

p.s., I get this skipping problem with all of the sample streams that you provided in streams.cfg. My computer is connected to the Internet via DSL.

It seems that the path through the AudioThread::InputCallBack code is different when being served from a shoutcast stream vs. from the Rio HTTP server.

This is basically correct. The path chosen actually depends on whether or not the music stream contains metadata (which contains the current song title).

There are these weird for loops to read in stuff related to metadata. Could you explain what you are doing there. I just couldn't understand why you can't simply do a single fread(). Though, I am sure you have a reason for this.

The reason for this filthy mess of code is because the Shoutcast metadata is embedded in the stream every n bytes. Because of this you have to keep track of how many bytes you've read so you can know when to expect the metadata to occur. It gets even worse because in the InputCallback, MAD passes in data which it did not yet process which must be accounted for. I'm open to suggestions on how to clean this up

Shouldn't you grab the ClassMutex before calling Display.Update for the metadata? You seem to do that in the OutputCallback code. Or is that lock used to protect something else?

The way I did the mutexes is that each Thread class protects itself with it's own mutex. So, if you look in Display.Update() you'll find that the Display locks itself inside that function. Looking at the lock in the OutputCallback that you're talking about, I'm not sure if it's needed. I'll have to look more closely at that.

Dave,

I recommend you take a look at httpinput.cpp in the freeamp code base. It does things a bit cleaner (i.e., no for loops).

I might be committing a fopa, but I'll include the file as an attachment to this message. Peek at the code in HttpInput::WorkerThread().

Marc

I might be committing a fopa

<grammar police> Don't you mean faux pas, which I believe is French for "false step"? </grammar police>

I think I found the problem with dropouts in streaming playback.

I have noticed a few streams that exhibit these problems for me, but I had just assumed that it was a slow server because changing to another feed of the same stream almost always cleared up the problem. Anyway I was playing around with the buffer on one of the streams that did have dropouts and found that decreasing the buffer size eliminated the dropouts.

I'm pretty sure what's going on is that the InputCallback always tries to fill the buffer as much as possible, and since streams are more ore less realtime it can end up waiting too long to fill the buffer and the output buffer empties before MAD can refill it. To solve this I'm going to create another thread that is solely responsible for collecting and buffering input from the network. InputCallback will then fill it's buffer from the other thread's buffer.

Hopefully this will take care of the dropouts...

It seems I truly committed a "faux pas".

What the ETA on the fix?