First i am not reading from a file, but recording a live music program ( LP's) from the input of a soundcard. Second, i don't think i am sending any clocked digital audio from one pi to the other, but rather packed data taken on some buffer on the recording pi which is copied or transported by TCP to another buffer on the receiving side.
I suppose, on the receiving side Sox reads the buffer expecting to find data corresponding to a flac audio stream, but i don't think that there is any timing info in these data. The data are simply stacked in chronological order and without losses in a receiving buffer and sox, if provided by the command line the right parameters will make a properly clocked audio stream.
So i guess, as commented by Phofman, the size of the buffers is what avoids failures due to the slight difference of speed of the 2 clocks. I have no idea about how TCP manages this buffering, but i guess it will do that the same way transporting audio, video, text, images, of whatever kind of data. I think TCP has no idea of the nature of the data it transports, nor this matters at all.
Ah, thanks. That's indeed a different usage.
TCP as you say doesn't care about its content and incorporates flow control to handle source and destination running at different rates. The format of the sox stream will I think have both the music data and embedded clock ticks in it but that's irrelevant to TCP and not our problem (and would be the case for file based play as well).
I understand the problem to be that your input source (the sound card) is producing the data stream at a fixed rate. Unlike a file read which can run at huge speed and who's rate can be determined through flow control by the rate its destination requires.
I guess you could play one side of the lp to a file then send that file as per my original suggestion. This would I think provide the equivalent of an infinite sized buffer but given that a 10 second buffer is overkill for you I guess you don't want to wait many minutes for the side to finish playing instead
Out of interest, do you just play the lp once to digital or each time you listen to it?
When sox receives audio data it must be told how to read these data and this information is not embedded into the data itself like in spdif or i2s,or hdmi data. In case of files like wav or flac this information is in a header which read by sox as an instruction manual which tells how to read the data. With headless files or raw data received on stdio ( pipe) you have to tell sox absolutely everything regarding the structure of these data like:
sox -r 44100 - b 16 -c 2 - e si -...
so that these data are "raw" information without any timing /format embedded in it.
You can even fool sox telling it to play DonQuijoteDelaMancha as if it were a CD audio:
Will play the pdf!
Last edited:
I guess you could play one side of the lp to a file then send that file as per my original suggestion. This would I think provide the equivalent of an infinite sized buffer but given that a 10 second buffer is overkill for you I guess you don't want to wait many minutes for the side to finish playing instead
I think that the latency is what the protocol needs to do its job properly. If we use different protocols that allow data losses, or stream a lossy format the latency will be reduced. As i commented before i have a similar latency streaming in http with vlc, so that i suppose it is the result of to make a very conservative choice of transmision protocol.
Might try icecast, though it's not the favorite picky fine *** hipster audiophile choice...
We old guys don't rip anything, neither LPs nor CD!
I find the management of a musical library such a pain in the *** that i have decided long ago that:
THOU WON'T RIP NOR DOWNLOAD ANYTHING!
I buy CDs, LPs, and for the rest use streaming media (url radios, TIDAL, Apple Music...)
We old guys don't rip anything, neither LPs nor CD!
I find the management of a musical library such a pain in the *** that i have decided long ago that:
THOU WON'T RIP NOR DOWNLOAD ANYTHING!
I buy CDs, LPs, and for the rest use streaming media (url radios, TIDAL, Apple Music...)
Next thing is you're going to want a sensor hooked up to start up the streams when you lift the arm
Next thing is you're going to want a sensor hooked up to start up the streams when you lift the arm
What do you think i am inquiring about the rpi's gpio for?
Here is an update to my latest streaming audio experimentation:
Never being satisfied with some that is not working 100% I decided to again try experimenting with Gstreamer in place of VLC. Gstreamer 1.2 is included with Raspbian on the Raspberry Pi (my preferred platform) so it makes sense to make use of it.
First I tried using a Gstreamer pipeline for the clients only. This kept multiple clients in sync better than VLC could. VLC had been pretty good at this overall but de-sync'd just enough now and then to be able to notice it on certain instruments. With Gstreamer making a noticeable improvement on the client side I decided to try and convert the stream server over to a Gstreamer pipeline as well.
When I used Gstreamer on the server and used some of the tricks that I had learned since the last time I attempted to use this platform, lo and behold I got it to work, and work pretty well, too. This stands in contrast to the endless frustration I had with my previous attempt at writing Gstreamer pipelines.
I've been listening to the system for the last 5 or 6 hours. Quality of the audio seems better overall than with VLC, which probably had a lot of playback jitter. I'm streaming PCM at 16/48 (just like I was doing with VLC) under the RTP protocol. I do have to supply the format, bitrate, number of channels, and so on but in my system these are always fixed.
During this process I took a look at my previous Gstreamer attempts to try and figure out what might have prevented me from being successful back then. I know that I have since upgraded my USB WiFi dongles and now have better connectivity and bandwidth. Also I am now using a 16 bit RTP payload instead of a 24bit payload, which should make the transport a little lighter. I'm still not sure of the compatibility of 24 bit PCM with ALSA under Linux, but I know that 16 bit works like a charm. I'm also no longer doing any transcoding (I was using AAC before) and am just streaming the PCM audio that my player software on the server spits out.
The small yet annoying quality issues I was having when streaming RTP using VLC might be behind me now and I can think about getting back to building and listening to speakers for a change...
Never being satisfied with some that is not working 100% I decided to again try experimenting with Gstreamer in place of VLC. Gstreamer 1.2 is included with Raspbian on the Raspberry Pi (my preferred platform) so it makes sense to make use of it.
First I tried using a Gstreamer pipeline for the clients only. This kept multiple clients in sync better than VLC could. VLC had been pretty good at this overall but de-sync'd just enough now and then to be able to notice it on certain instruments. With Gstreamer making a noticeable improvement on the client side I decided to try and convert the stream server over to a Gstreamer pipeline as well.
When I used Gstreamer on the server and used some of the tricks that I had learned since the last time I attempted to use this platform, lo and behold I got it to work, and work pretty well, too. This stands in contrast to the endless frustration I had with my previous attempt at writing Gstreamer pipelines.
I've been listening to the system for the last 5 or 6 hours. Quality of the audio seems better overall than with VLC, which probably had a lot of playback jitter. I'm streaming PCM at 16/48 (just like I was doing with VLC) under the RTP protocol. I do have to supply the format, bitrate, number of channels, and so on but in my system these are always fixed.
During this process I took a look at my previous Gstreamer attempts to try and figure out what might have prevented me from being successful back then. I know that I have since upgraded my USB WiFi dongles and now have better connectivity and bandwidth. Also I am now using a 16 bit RTP payload instead of a 24bit payload, which should make the transport a little lighter. I'm still not sure of the compatibility of 24 bit PCM with ALSA under Linux, but I know that 16 bit works like a charm. I'm also no longer doing any transcoding (I was using AAC before) and am just streaming the PCM audio that my player software on the server spits out.
The small yet annoying quality issues I was having when streaming RTP using VLC might be behind me now and I can think about getting back to building and listening to speakers for a change...
Quick update on timing and synchronization under Gstreamer:
I am using RTP to control the timing of playback across the various clients in each system. In Gstreamer an RTP "jitter buffer" is used on the client end to buffer the incoming data and reconstruct the timing from the RTP timestamps AND the system clock. Here we go again with clocks! I noticed that after an hour or so that the system was slowly drifting out of sync. The reason for this was that the jitter buffer "mode" was set to "SLAVE" by default if no other mode is invoked. I changed this to mode=SYNCED, which is described HERE as "sender and receiver clocks are synchronized, like RTP_JITTER_BUFFER_MODE_SLAVE but skew is assumed to be 0. Good for low latency communication when sender and receiver clocks are synchronized and there is thus no clock skew". In my system I still use NTP to syncronize the clocks of the audio clients to the clock in the audio server. This makes sure that all the client clocks are running at the same rate, to within about 500 microseconds or better. I have shown in the past that I can achieve this level of sync over WiFi using NTP.
After the mode change I ran the system continuously for the last several days. Each morning I dialed up some music and immediately the system would spring to life with the audio playback working perfectly. At no time over the last few days have I been able to detect a loss of sync between clients, so I think that this is the configuration that I will stick to for now. Play back quality is very good.
I am using RTP to control the timing of playback across the various clients in each system. In Gstreamer an RTP "jitter buffer" is used on the client end to buffer the incoming data and reconstruct the timing from the RTP timestamps AND the system clock. Here we go again with clocks! I noticed that after an hour or so that the system was slowly drifting out of sync. The reason for this was that the jitter buffer "mode" was set to "SLAVE" by default if no other mode is invoked. I changed this to mode=SYNCED, which is described HERE as "sender and receiver clocks are synchronized, like RTP_JITTER_BUFFER_MODE_SLAVE but skew is assumed to be 0. Good for low latency communication when sender and receiver clocks are synchronized and there is thus no clock skew". In my system I still use NTP to syncronize the clocks of the audio clients to the clock in the audio server. This makes sure that all the client clocks are running at the same rate, to within about 500 microseconds or better. I have shown in the past that I can achieve this level of sync over WiFi using NTP.
After the mode change I ran the system continuously for the last several days. Each morning I dialed up some music and immediately the system would spring to life with the audio playback working perfectly. At no time over the last few days have I been able to detect a loss of sync between clients, so I think that this is the configuration that I will stick to for now. Play back quality is very good.
Charlie,
I've been reading this thread for awhile and watching your comments about your streaming system and software trials. I have a question about the latency problems you keep running up against. If you were only using a single pair of speakers and they were receiving streaming audio from a WiFi source would you expect this type of problem with clock drift? I'm working on a design for a self powered speakers that will use both WiFi and Bluetooth receivers and am very curious about this situation if someone was to use the speakers with a HT type of setup for movies and such. I don't think with just music you would probably ever notice an issue but once you bring in video syn perhaps then this can become a problem.
Thanks for any answers,
Steven
I've been reading this thread for awhile and watching your comments about your streaming system and software trials. I have a question about the latency problems you keep running up against. If you were only using a single pair of speakers and they were receiving streaming audio from a WiFi source would you expect this type of problem with clock drift? I'm working on a design for a self powered speakers that will use both WiFi and Bluetooth receivers and am very curious about this situation if someone was to use the speakers with a HT type of setup for movies and such. I don't think with just music you would probably ever notice an issue but once you bring in video syn perhaps then this can become a problem.
Thanks for any answers,
Steven
With a single client (e.g. same client sends audio to a pair of loudspeakers) you would never notice anything. The drift is at most a few tens of milliseconds over hours. My system has a separate client for each loudspeaker, or subwoofer, in the system, and I can have multiple systems. For that reason getting each client to be closely in sync is important because in a pair of loudspeaker if one is a few milliseconds different than the other in playback you can notice it pretty easily, even if the drift is very slow.
Please note that latency is not the problem for me - I have no problems with moderate amounts of latency, in fact there is probably 300-500 msec of latency in my system depending on how much buffering I want to use. Latency and synchronization are two different things. You can have everything delayed by 1 second (latency) and have perfect synchronization - you would only notice when you stop, start, or change the playback, volume, etc. Those changes would be delayed by 1 second. If the delay is unchanging over time you can simply delay video/audio to match. On the other hand, you can also have very low average latency (low delay) but different playback clients are out of sync. For audio this becomes a big problem and you can eventually get effects like echo if the synchronization reaches a couple of hundred milliseconds.
There are many different ways to stream audio to a single client:
Bluetooth
Airplay/DLNA
SSH
RTSP/RTP
HTTP
etc.
When you have multiple clients things become a lot more complicated.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.