Clear Buffer @ SAM - a solution (!?)

[GKIye]

Hi everyone,

 

ok ... do not shoot the messenger

 

Lately I have thought a lot about how to fix the "clear buffer" issue for real

 

When ?

To my project it happens most often if the encoder has reached "streamed 1,6GB"

 

In fact it looks logical to Me if it happens always more or less at that 1,6GB value, that it can be a critical amount of data

(don't ask Me the technical details ...)

 

So I wrote a stupid simple PAL who is activated once a day by using the Event Sheduler

(mine is sheduled at 06am)

encoders[0].stop;

encoders[0].start;

It stops and start the encoder in no time ... and it don't affects the music at the stream

(so without interruptions)

As well this action don't affects the media player (so no buffer etc ...) and no loss of listeners

 

If it also works out to You, please write your comment

[shoutcaststreaming]

encoders[0].stop;
encoders[0].start;

To be clear, that will work on encoder #1.

[GKIye]

Offcourse ...

 

but what I wrote is "just" an idea ... I added it to my sheduler and it looks that it works ok

Time will learn if it also fix (more or less) that "clear buffer" issue

(I'm not technical)

encoders[0].stop;
encoders[0].start;

To be clear, that will work on encoder #1.

[SmoothJazz]

I highly doubt the issue is "just" because you have streamed a certain number of bytes on an encoder and may just be coincidental you see it at that number of bytes streamed.. If you would take the time to run a WinMTR report while you are seeing this behavior from your SAM machine to the streaming server, I bet you will see significant packet loss at some hop near or at the streaming server.

[GKIye]

Thanks Rob for your feedback

Appreciated !

I run from time to time tests to check my pings and stream connection with the streamserver

and those are always very good

I highly doubt the issue is "just" because you have streamed a certain number of bytes on an encoder and may just be coincidental you see it at that number of bytes streamed.. If you would take the time to run a WinMTR report while you are seeing this behavior from your SAM machine to the streaming server, I bet you will see significant packet loss at some hop near or at the streaming server.

I know all of this about the clear issue is old stuff were We are talking about

 

but as I wrote : Time will learn if it works (fix) these or similar problems

The more input of ideas and feedback, the better the chances are to finaly find "the" solution

[techmonkey]

I doubt this error is anything to do with your net connection.

 

Don't breate me for saying this, but when we switched to different piece of automation software (same shoutcast provider, same internet connection) and the issue had gone away. Switch back to SAM, hey presto the problem is back.

[BWorld]

I doubt this error is anything to do with your net connection.

 

Don't breate me for saying this, but when we switched to different piece of automation software (same shoutcast provider, same internet connection) and the issue had gone away. Switch back to SAM, hey presto the problem is back.

 

As much as I liked SAM when I used it, I can definitely agree with this statement.

[djgary72]

I've said all along that the problem was never the stream host or network issues but an Issue within the SAM Encoders. I did a Blog post about this issue. Even the Winamp DSP encoders that Spacial made had the same problems.

 

http://djgarybaldy.co.uk/sam-broadcaster-unable-to-send-data-fast-enough/

 

The problem went away when i used different encoding software.

 

Of course tho hardened SAM users will think I'm just bashing the software. I'm not I'm just being honest about what others and myself have had issues with.

[GKIye]

Thanks to all for Your replies so far

Appreciated !

[isaacl]

Did you ever try increasing the buffer in SAM?

Config -> Audio Mixer Pipeline -> Air Out (bottom right), look at the right side, under Buffer Settings.

I currently have mine set to 15 packets, and 20 ms for the packet time, and I haven't had any issues since I increased those a few years ago.

[GKIye]

Thanks for Your feedback Isaac,

 

I know that this section is about the only spot where adjustements can be made (concerning my topic)

Since my most recent reply I adjusted the latency to an amount equal (more or less) to what is send to the stream server ... (results after I made a "tracert" ... known as CMD > tracert + destination of server)

"Source > the amount of pings and their values > untill the server"

The results learned Me that there're 10 hops with an average packet time between 42ms and 50ms

 

Since I changed the settings to it the "clear buffer" still appears, but lesser than before

and strange enough, since I'm using my own stupid simple script (stop > start encoder = twice a day) the error appears lesser than before ...

Lesser, however it appears ...

 

I'm using SAM since 2002 / 2003 ...

and yes as Gary quoted it stays an issue that affects streaming

 

I'm not the guy who makes setups of all excisting streaming softwares ... for reason that after a while data can create conflicts in between similar softwares ... and thats something that I don't like

 

So yes, I stay a SAM user, however the question remains : why appears that specific issue in that type of software and not in similar softwares ?

 

A solution ? Maybe, but where ... ?

At no place at the www I found an answer who covers and who is solving the issue (not at the SAM forum, and not at other places ...)

I currently have mine set to 15 packets, and 20 ms for the packet time, and I haven't had any issues since I increased those a few years ago.

Besides this ... I wanna ask You to check out my stream : SAM settings, sound, quality etc

a review is most appreciated

[isaacl]

Which encoder type are you using?

I would guess that this error may have something to do with the encoder type that you're using, and the encoder settings.

I run my copy of SAM on a Windows VM I have on my server, and I haven't had any issues like that.

Even when I had SAM on a remote machine, which had a decent internet connection, but nothing great, I never really had any issues, besides for once in a while getting the error that SAM can't send the data fast enough, which normally happens when something temporarily goes wrong with my data connection.

And I'm really not great with sound, so I wouldn't be of much help... ;)

[GKIye]

As I'm using since years ... MP3 (PRO)

 

Since Your recent post about Your buffer settungs, I'm using Your settings ... and I'm keeping my fingers crossed untill now

Which encoder type are you using?

And I'm really not great with sound, so I wouldn't be of much help... ;)

and ... about the sound ... I was just asking if You liked the sound

PS : say "yes, I love it" ... LOL

 

Thanks for Your reply and time ... appreciated

[isaacl]

I've been using the Legacy MP3 (ACM Codec) encoder for a while, with no issues - it may be worth trying that, to see if it solves your buffer issue.

You can find the instructions on how to setup the encoder here: http://support.spacialaudio.com/forums/viewtopic.php?f=20&t=22376

If you're running a 64 bit version of Windows, you would need to follow the instructions in the LAME ACM download to install the codec on a 64 bit system.

Also, since they took out the MP3 (ACM) encoder in version 4.7.4, you need to run SAM with the /LEGACYENC option to be able to create a new MP3 (ACM) encoder.

To do that, right click the SAM shortcut, click properties, then at the end of the path in the target box, add a space, and then "/LEGACYENC" (without the quotes), and then start SAM using that shortcut.

Once you run that and set up the encoder, you shouldn't need to use that option again to actually use the encoder in SAM.

And I took a quick listen to your stream - it sounds pretty good!