Why NTP synch?
I think it's probably the wrong rabbit hole to dive into trying to reinvent time synchronized streams. What's the goal? Not trying to challenge the idea, but if you could explain like speaking to a dim child, I'd appreciate it... BTW, I do dream of an active multiway speaker that only has ethernet and power connections, all done with free software - speakers figure out their roles by themselves. I have strange dreams.
For audio applications I see recommendation to turn off NTP (f.ex at linuxmusicians.org). NTP works by slewing the clock faster or slower once it detects a difference over its threshold. Remember that every time request is a network connection to the time server, so trying to make it work within audio tolerances on a machine with no hardware clock is going to generate a lot of network traffic, ie. load. There are ready made hardware clock addons for Raspi which could help.
OTOH, seems people do use NTP for synchronized playing of streams into different rooms. All machines should be synced to a local time server, not a server on the internet.
I don't know RTSP. The Jack audio connection kit has support for working over the network, between several jackd instances. It's a server + slaves system. I think it's primarily meant for offloading audio processing to another CPU. Not supported over Wifi for obvious reasons. I've only looked at the documentation so far, but it seems it could be wrangled to push streams to a remote Raspi for playing.
I'm still feeling my way around this.
I think it's probably the wrong rabbit hole to dive into trying to reinvent time synchronized streams. What's the goal? Not trying to challenge the idea, but if you could explain like speaking to a dim child, I'd appreciate it... BTW, I do dream of an active multiway speaker that only has ethernet and power connections, all done with free software - speakers figure out their roles by themselves. I have strange dreams.
For audio applications I see recommendation to turn off NTP (f.ex at linuxmusicians.org). NTP works by slewing the clock faster or slower once it detects a difference over its threshold. Remember that every time request is a network connection to the time server, so trying to make it work within audio tolerances on a machine with no hardware clock is going to generate a lot of network traffic, ie. load. There are ready made hardware clock addons for Raspi which could help.
OTOH, seems people do use NTP for synchronized playing of streams into different rooms. All machines should be synced to a local time server, not a server on the internet.
I don't know RTSP. The Jack audio connection kit has support for working over the network, between several jackd instances. It's a server + slaves system. I think it's primarily meant for offloading audio processing to another CPU. Not supported over Wifi for obvious reasons. I've only looked at the documentation so far, but it seems it could be wrangled to push streams to a remote Raspi for playing.
I'm still feeling my way around this.
Well, my scheme is working, even if it has some warts. It's the multiway speaker with only ethernet (WiFi included) and power connections that you mention...
The fact is that the clock rate of any individual computing unit will vary from the next one. This can mean that, if you started playing a track on each one (without any synchronization), after 10 minutes they could be 1 second or more different. Introduce a time synchronization method - this tries to adjust the playback "speed" to keep the playback in time with a timestamp. But to do that it seems (to me) that you need a very good estimation of what time it is. We are right back to the clocks not being synchronized. NTP tries to keep the local clock in time with one or more networked time servers by adjusting various things.
RTSP is a bit of a black box for me, although I understand its general working principles. I haven't gone as far as trying to read through the source code, but I finally figured out that VLC receives the stream and then passes it on to Live555 for demuxing and decoding (back to PCM?) before it is routed (by VLC? by Live555?) on to ALSA. I definitely do not have the low level knowledge of these processes that others have, and it's not really what I have time to dive into at this point. In any case, playback is sync'd to an acceptable degree for me to move on to implementing this in an active speaker that I can show off to others, yes even when using WiFi. At least it works in my home... Let's see how it works in the field at Burning Amp.
Attached is a pic of my current LADSPA/ecasound loudspeaker test bed using a pair of Raspberry Pis (one per speaker). The Pis are receiving streaming audio over wireless ethernet, processing it with ecasound to implement the crossover filters, and then outputting to the active MTM speakers. I'm listening to some music and all is well.
Although I am still ironing out some final details for headless operation, I am planning to bring these speakers to Burning Amp to demo the systems to anyone who wants to drop by.
.
Although I am still ironing out some final details for headless operation, I am planning to bring these speakers to Burning Amp to demo the systems to anyone who wants to drop by.
.
Attachments
Last edited:
After ironing out some bugs in the startup scripts so that this can all run headless I am pretty satisfied with the result. Best result is had when the Pis are left on all the time so that kernel time is well sync'd. If there are gliches or delay becomes apparent I can stop and restart streaming at the server or the client, or do the same with ecasound on the client, and often this results in a re-sync-ing of everything. I assume issues arise as the clock is being adjusted aggressively by NTP after restart(s) and while playback is occurring. Just a guess on that...
Anyway, just so I had another DAC to compare to the $10 ones that I have been using, I decided to exchange those for a pair of minDSP miniSTREAMERs (USB SPDIF I/O) connected to a couple of DACs that I reviewed on this site a while back (see: http://www.diyaudio.com/forums/digi...dif-input-24-96-dac-only-40-measurements.html). So far this setup is playing away, with only a very minor hitch at the beginning. What was nice is that to make this change I only needed to make a single change to the ecasound output specifier, from
to
So it should be easy to "roll" DACs to see which you like best, etc.
I have written some shell scripts that I can use to start and stop vlc (the streaming client/player). These run on startup. For instance, if I want to stream to the speakers from another machine I can SSH to each Pi, supply the new server IP address, and then re-start the vlc client. Seems to be working smoothly now. I will continue to test over the next days and weeks in the background. It's set up in my office so I can do other things while listening to the audio playback.
Anyway, just so I had another DAC to compare to the $10 ones that I have been using, I decided to exchange those for a pair of minDSP miniSTREAMERs (USB SPDIF I/O) connected to a couple of DACs that I reviewed on this site a while back (see: http://www.diyaudio.com/forums/digi...dif-input-24-96-dac-only-40-measurements.html). So far this setup is playing away, with only a very minor hitch at the beginning. What was nice is that to make this change I only needed to make a single change to the ecasound output specifier, from
Code:
-o:alsa,front:DAC
Code:
-o:alsa,front:miniSTREAMERI have written some shell scripts that I can use to start and stop vlc (the streaming client/player). These run on startup. For instance, if I want to stream to the speakers from another machine I can SSH to each Pi, supply the new server IP address, and then re-start the vlc client. Seems to be working smoothly now. I will continue to test over the next days and weeks in the background. It's set up in my office so I can do other things while listening to the audio playback.
Last edited:
Hi Charlie,
I just built a few of these boards... if you're curious (I've got two spare bare boards). They contain a 5v supply (always on) and a 15A/250V bistable relay along with two driver transistors. It takes two GPIO pins from my RPI and turns power on and off. The upper-left connector is a stock USB female pointing up (to save space).
I just built a few of these boards... if you're curious (I've got two spare bare boards). They contain a 5v supply (always on) and a 15A/250V bistable relay along with two driver transistors. It takes two GPIO pins from my RPI and turns power on and off. The upper-left connector is a stock USB female pointing up (to save space).
Attachments
Last edited:
I still need to put something like this together... am considering using GPIO pins when the Pi is available, but may make a board that can also be used along with my audio-output-driven, LADSPA based signaling since I am planning to use a small computer that doesn't have something like a GPIO pin available.
I will have to roll my own boards because I want to use up some of my relay stock... thanks for offering, though!
UPDATE on the system...
Actually, there isn't really anything to report about the LADSPA plug ins. These have been working perfectly since I released them!
I thought I would post an update on my efforts to stream audio over Wifi. I have been thinking about the easiest way to bring my system to Burning Amp. I don't want to have to do a bunch of configuration after I arrive, re-setting of IP addresses for headless systems and so on, and I made the decision to switch move whole system to its own private WiFi network using an inexpensive (e.g. $20 on sale) 802.11g/n router that I picked up for this kind of need. After I got the Pis moved over to the new WiFi network, I set up and began to use a laptop as the streaming server. I realized that I was experiencing some problems with the audio like dropouts and so on, so I worked for a couple of days to switch the (windows 7) laptop over to NTP time sync for the clock. I have also been tidying up NTP on the Pis, and the result has been amazing. I am able to get them to be pretty tightly sync'd to well under a 1 millisecond of each other, and about 1-1.5msec to a local Stratum 1 time server. This is only using internet communication over WiFi! Pretty amazing. But I was still having problems with the audio, and after enabling NTP stats logging on the laptop I discovered that the time just wasn't stabilizing very well for whatever reason. So today I replaced that with a Baytrail 4-core machine that I recently built for audio testing. But even after I got that configured for streaming I was STILL HAVING PROBLEMS (caps for frustration emphasis). What was this!!?! I was having such great uninterrupted and wonderful audio before... what could be the problem? Well before I was using my desktop... hmm ok, what is different? Oh... it's plugged into the router directly by an ethernet cable. So I dug out another cable and connected the BayTrail system to the new router. Sure enough, the audio playback was suddenly as glitch free as before.
So, it seems that the wireless link (at least using the WiFi adapters and protocols that I have at my disposal at the current time) is just not up to the task of bidirectional real-time audio transfer, even if the audio in question is "only" mp3 format, e.g. compressed. But with a wired connection things are working out great, so I will stick with that.
This is a bit of a bummer, since I was envisioning walking around with my laptop at Burning Amp to show how I could control the audio from anywhere I happened to be at the time (within WiFi range at least). This requires a bit of a re-think. I am now envisioning the (headless) audio streaming server directly connected to the router with a cable and a remote interface or remote desktop running so that I can control the player software on the server from my laptop (or mobile device e.g. tablet, etc).
In any case, that would be frosting on the cake. The important part is that the wireless audio streaming seems to be working great as long as the streaming server is "wired", and of course the LADSPA based DSP crossovers are working flawlessly. This has really been a fun learning experience! I hope the ride continues like this. 😎
.
Actually, there isn't really anything to report about the LADSPA plug ins. These have been working perfectly since I released them!
I thought I would post an update on my efforts to stream audio over Wifi. I have been thinking about the easiest way to bring my system to Burning Amp. I don't want to have to do a bunch of configuration after I arrive, re-setting of IP addresses for headless systems and so on, and I made the decision to switch move whole system to its own private WiFi network using an inexpensive (e.g. $20 on sale) 802.11g/n router that I picked up for this kind of need. After I got the Pis moved over to the new WiFi network, I set up and began to use a laptop as the streaming server. I realized that I was experiencing some problems with the audio like dropouts and so on, so I worked for a couple of days to switch the (windows 7) laptop over to NTP time sync for the clock. I have also been tidying up NTP on the Pis, and the result has been amazing. I am able to get them to be pretty tightly sync'd to well under a 1 millisecond of each other, and about 1-1.5msec to a local Stratum 1 time server. This is only using internet communication over WiFi! Pretty amazing. But I was still having problems with the audio, and after enabling NTP stats logging on the laptop I discovered that the time just wasn't stabilizing very well for whatever reason. So today I replaced that with a Baytrail 4-core machine that I recently built for audio testing. But even after I got that configured for streaming I was STILL HAVING PROBLEMS (caps for frustration emphasis). What was this!!?! I was having such great uninterrupted and wonderful audio before... what could be the problem? Well before I was using my desktop... hmm ok, what is different? Oh... it's plugged into the router directly by an ethernet cable. So I dug out another cable and connected the BayTrail system to the new router. Sure enough, the audio playback was suddenly as glitch free as before.
So, it seems that the wireless link (at least using the WiFi adapters and protocols that I have at my disposal at the current time) is just not up to the task of bidirectional real-time audio transfer, even if the audio in question is "only" mp3 format, e.g. compressed. But with a wired connection things are working out great, so I will stick with that.
This is a bit of a bummer, since I was envisioning walking around with my laptop at Burning Amp to show how I could control the audio from anywhere I happened to be at the time (within WiFi range at least). This requires a bit of a re-think. I am now envisioning the (headless) audio streaming server directly connected to the router with a cable and a remote interface or remote desktop running so that I can control the player software on the server from my laptop (or mobile device e.g. tablet, etc).
In any case, that would be frosting on the cake. The important part is that the wireless audio streaming seems to be working great as long as the streaming server is "wired", and of course the LADSPA based DSP crossovers are working flawlessly. This has really been a fun learning experience! I hope the ride continues like this. 😎
.
So. A music server set up headless. Hm. MPD? JRiver? Control from a tablet? Works...
You're getting closer to my setup all the time. Server gets files from NAS via wireless, and the rest is simple wires. Control from laptop or tablet via same wireless.
You're getting closer to my setup all the time. Server gets files from NAS via wireless, and the rest is simple wires. Control from laptop or tablet via same wireless.
I'm still thinking that the sync over wifi will be problematic w/o some sort of hw time stamping.
Another thought - the speakers need to be plugged in for power, right? What if the Ethernet connection were made over the power line? More stuff to buy and setup, but at the end of the day there's only one connection to the speaker.
Another thought - the speakers need to be plugged in for power, right? What if the Ethernet connection were made over the power line? More stuff to buy and setup, but at the end of the day there's only one connection to the speaker.
Well, the user-interface side our systems might share some conceptual similarities (remotely and wirelessly control a music server from another device) but that is where things kind of diverge. The whole purpose of my streaming audio system is to implement multiple, independent, synchronized playback devices... that's a separate (headless) playback system for each speaker, subwoofer, etc. all operating synchronously. This can be implemented simple as a pair of speakers or expanded to any number of independent system distributed around (e.g. my home). Audio is streamed to these over a WiFi connection, and each playback device also implements a software-based DSP crossover using the LADSPA plugins that I wrote. I have been working on lots of different parts of the whole, and so far things have been going fairly well during testing.
But the idea of remotely controlled playback from a centralized server is common to both our efforts and I am sure that I could learn a few things from your system in that department.
Nope! Time stamping is already provided in the transport protocol. All hardware is brought onto the same timebase using NTP.
Well sure they are active speakers after all, so AC mains power is more or less required. But that's the only "wire" that connects the speaker(s) to anything else. The rest is done via wireless 802.11g/n. Like you say, at the end of the day there is only one connection to the speaker(s).
Now that I have had some sleep I wanted to post some more thoughts on ethernet over power line. I've looked into this in the past. Technology has gotten more mature lately and there are many competing products. For a basic 2-way speaker setup you would need three adapters - one to inject the TCPIP onto the power line and one at each speaker. Typically a set of two of these retails for a minimum of $50 (which isn't bad actually) and up. Performance can vary, and I found a couple of recent articles that review quite a few different models and has throughput numbers. See:
Best power-line adapters of 2015 - CNET
Tech Hive: The essential guide to powerline Ethernet adapters (including 12 hands-on reviews)
The one major advantage of this technology, assuming the connection is reliable, is that it can offer something similar to wired ethernet speeds (actual speed depends on several factors, and the capabilities of the unit that is purchased). This could make streaming of PCM or high sample rate FLAC a possibility and that would open up some new doors.
The one major (potential) problem is this: in the USA power is supplied to homes as 2-phase, that is two 115Vac single phase lines that are 180 degrees out of phase with each other. Your home is supplied with power in various branches or circuits, and each of these is connected to one of the 115Vac single phase lines at the breaker box. Typically the home's load is split evenly between each single phase line to balance the loading on each. This makes it quite likely that you would plug in the "injector" adapter for the ethernet into one outlet but when you plug the "receiver" adapters into the remote outlet where your powered speakers are located it just so happens that those outlets are on the other single phase source and are therefore electrically isolated. You would not be able to establish a connection using these devices. Of course this could be solved by re-assigning the branches involved so that they are all on the same single phase supply, but rooting around in my electrical panel and doing this kind of thing is best left up to an electrician. If you are serious about this course of action, it's certainly possible.
The other potential issue that has made me hesitate in the past, and is still the case today (see the Tech Hive review) was reviewers saying that these adapters worked well when the distance between receptacles (where the adapters were plugged in) was short (like 10 feet or less) but when the distance was large (like when the adapters were on separate branches that only connected at the main electrical panel) the performance was slow and the connection intermittent. This represents a real red flag to me, so I would want to see some real world testing unless I can pick up a pair of these on the cheap and test them myself. There are still more cons that you can read about if you poke around and read the various info on the web (believe what you want).
In summary this technology has some very interesting possibilities, but hidden drawbacks may ultimately mean that may not be a substitute to WiFi for reliable audio streaming in all cases. On balance, 802.11ac may be a better alternative for high speed audio streaming. I've just been using the equipment that I happen to already own or was cheap to purchase. Looking at higher bandwidth audio streaming is something that I intend to do down the road. Here are some recent test results on ac and beamforming n WiFi routers that might be of interest to you:
http://www.tomshardware.com/reviews/wi-fi-802.11ac-router,3386-12.html
Last edited:
Several years ago, I tested three different "ethernet over power line" products. Perhaps that has improved since, but back then, all three failed even minimal connectivity in my home, even in the same room. Early wifi was far better, faster, and more reliable. That is one reason that when we built our new home, we fully wired it with cat 10e from nearly every room to the mechanical room, where I installed a patch panel...
The manufacturers claim that the two segments of the house wiring can be bridged with a capacitor to allow network connectivity throughout the house, though I've not attempted to go there.
The manufacturers claim that the two segments of the house wiring can be bridged with a capacitor to allow network connectivity throughout the house, though I've not attempted to go there.
Things are moving along...
I realized that, since my streaming server is running linux, I would be able to remotely access it using X windows. First I had to apt-get install the ssh server on my linux machine. Then on my Windows laptop I installed putty and Xming. After a couple of quick tweaks to configuration files on the linux machine, I'm up and running. Wow, was that simple. Even over a wireless connection the latency is barely noticeable.
Xming opens an X window just large enough to hold the application's window. No need for a full remote desktop. I can also access anything I need on the machine by opening other applications, terminals, etc.
In the system I am putting together, the server (like jplesset) can also be headless. I only need to have some device (current my laptop) that can run X windows to control the playlist and volume. Time to celebrate!
I realized that, since my streaming server is running linux, I would be able to remotely access it using X windows. First I had to apt-get install the ssh server on my linux machine. Then on my Windows laptop I installed putty and Xming. After a couple of quick tweaks to configuration files on the linux machine, I'm up and running. Wow, was that simple. Even over a wireless connection the latency is barely noticeable.
Xming opens an X window just large enough to hold the application's window. No need for a full remote desktop. I can also access anything I need on the machine by opening other applications, terminals, etc.
In the system I am putting together, the server (like jplesset) can also be headless. I only need to have some device (current my laptop) that can run X windows to control the playlist and volume. Time to celebrate!
Yep, that works. X was an excellent thought. Wish I could join you at Burning Amp, but not this year.
What I would really like is to use something like a tablet or android to use as the controller with a convenient charging station. This would need to serve Xwindows. Then it will have more the look and feel of a fancy GUI type remote control. Will have to look into this a bit more and take a plunge.
If anyone runs X from a tablet or mobile device and would like to share their experiences, please post or PM me.
Charlie, it's not really "low cost", but a Microsoft Surface Pro looks like a tablet, and will run anything my desktop will...
or
You could install on your android box the following X11Server
https://play.google.com/store/apps/details?id=au.com.darkside.XServer&hl=en
and follow few next steps:
or
You could install on your android box the following X11Server
https://play.google.com/store/apps/details?id=au.com.darkside.XServer&hl=en
and follow few next steps:
- start android-xserver
- start ssh client like ConnectBot (remote machine shoud have ForwardX11 yes)
- Run xclock, xterm ... any other X11 utilities
There is a recently released yet inexpensive 7" tablet from Asus that I am thinking of picking up tomorrow and trying with the Darkside X11 server you linked to. There is another X server, XSDL, that I also found (here: https://play.google.com/store/apps/details?id=x.org.server) and thought it sounds a bit buggy that might be an option as well. Not sure but it sounds like a real possibility. The only problem I see with the Darkside app is that it has no windows manager and when I want to add to my playlist in VLC it opens multiple windows depending on how I am adding tracks, etc. So that might be a no-go.
Last edited:
If you are still using VLC as the player, can't you just control it remotely via a browser:
https://wiki.videolan.org/Control_VLC_via_a_browser/
https://www.vlchelp.com/remote-control-smartphone-browser/
Another option is vlc-nox. Haven't tried it myself but seems to be suited for headless streaming server that doesn't require x.
https://packages.debian.org/sid/vlc-nox
Slick solutions are also the Volumio/Moode/Rune webinterfaces. Perhaps you can get some good code ideas from them to not only control the player but also scripts for changing the ladspa files. I remember you said it's not your preferred option, but I still recommend to try them out - if not for the player, but to see how they solved the interface. Here's the code:
https://github.com/volumio
https://wiki.videolan.org/Control_VLC_via_a_browser/
https://www.vlchelp.com/remote-control-smartphone-browser/
Another option is vlc-nox. Haven't tried it myself but seems to be suited for headless streaming server that doesn't require x.
https://packages.debian.org/sid/vlc-nox
Slick solutions are also the Volumio/Moode/Rune webinterfaces. Perhaps you can get some good code ideas from them to not only control the player but also scripts for changing the ladspa files. I remember you said it's not your preferred option, but I still recommend to try them out - if not for the player, but to see how they solved the interface. Here's the code:
https://github.com/volumio
Last edited:
I enabled the http control interface for vlc and played around with it for awhile. It's limited to playing local files.
I need the following in a music player:
1. play local music files
2. play music from a web address that I provide. Hardly any do this.
4. enable selection of audio output device. Must be able to choose ALSA devices under linux. So far this has eluded me for all but VLC. Most simply output to default audio or the like.
5. remote control from android or other means of all functions. I am doing this using X windows from a windows laptop, but not sure if X will really work from an android device well enough to be useful.
6. Prefer software to run under Unbuntu, as that is the OS on my music server.
vlc-nox is just VLC without its GUI. I would prefer a graphic interface. When you install the full VLC you get a command line version, cvlc, that seems very similar to vlc-nox. I already use cvlc for playback on my Pis, but it wouldn't be all that stellar on my server.
Of the Volumio/Moode/Rune trio you mention, do any of those satisfy all my criteria above? I think I have looked at these, and lots of others, and none of the ones I found really met all my needs/desires. But I am not married to VLC and if something better comes along I would be more than happy to try it out.