bpa wrote: > Just looking at code a look at s.cpp - is musicSocket open as Blocking > or non-Blocking ? > > If opened as Blocking then possibly the chunkiness of buffers which do > not align with how data is consumed by the player may end up with player > having too few bytes in buffer. > > The LMS way to handling streaming audio is to use non-Blocking socket > and then write as much data as possible until a EWOULDBLOCK is returned > (i.e. do not sleep on notional internal buffer boundaries - replenish > instead) - sleep when output buffers are all full. The Sleep can then > be at least 200ms. 16ms seems to be too small. > > If I can I understand the dynamics of why.csv - I'll see if it sheds > light.
Blocking. Let me point out that doing it this way worked for years, when the code ran on Windows and then on a raspberry pi. It appears to be moving it to Linux Mint on a NUC that made it fail (to prove that I need to move it back to a pi, which is some work). Maybe Linux Mint handles sockets differently than Raspian in some deep, strange way, but I'd be shocked. I think this is where I am confused. TCP is a stream protocol. The receiver can't (at least, better not) be able to tell whether the sender is using blocking or nonblocking calls. It's all just a stream of bytes to the receiver. Usually you use nonblocking writes when you have one thread driving several sockets and the thread doesn't want to get caught pending on any one of them when others are still writable; so usually you'd use select() to figure out which one is writable, and go write that one, and let select() block you when everything's full. It's an old school approach and maybe LMS does it that way, but I have a thread per client, so I should - in theory - be able to just write(), and if it blocks because the client hasn't caught up yet, that's fine, that's what blocking writes are for. There should be no difference between repeatedly writing to a non-blocking socket until it EWOULDBLOCK (and then, what, backing off and trying to send again later?), or doing a write that does, in fact, block. The receiver should see no difference because it's the same bytestream either way; if anything, blocking writes should deliver the bytes faster because there's no userland code getting involved to move the next piece along. But I will go down the path of madness and implement nonblocking writes of small pieces of the stream, and sleep briefly when I get EWOULDBLOCK, because I have nothing to lose. I mean maybe Linux has some terrible bug that causes blocking send() to fail to return promptly when bytes are delivered. That's about unthinkable but it's the only idea I can come up with. Of possible interest: I installed LMS and it upgraded the Classic to version 131, as expected. This combination is able to play the song without stuttering (so at least the hardware is ok). But when I made my own server talk to the upgraded Classic, it failed after just a few seconds (it didn't stutter, it just stopped, but the fullness size was 0 when it stopped.) So clearly LMS knows something about writing buffers to squeezeboxen that I don't. Unfortunately I'm bad at reading Perl, but I can see it's using nonblocking writes, so... ------------------------------------------------------------------------ ScottAM's Profile: http://forums.slimdevices.com/member.php?userid=69412 View this thread: http://forums.slimdevices.com/showthread.php?t=110986 _______________________________________________ unix mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/unix
