I am sitting here listening to Artisan Radio on my general use computer, in a browser (Vivaldi), from an RTL-SDR V3 BLOG plugged into another computer running the OpenWebRX+ server software.
Network traffic is much less than just using a client SDR program. About 150kbps data for the 2Mhz frequency range, and, unfortunately, around 190kbps for the Web Audio (for some reason, the only available option is WebPCM, not very compressed). Compare that to anywhere between 4Mbps and 14Mbps for the SDR++ server/client solution.
I've created a profile called RTL-SDR Artisan Radio, which users cannot change. They see 2Mhz of the FM band (I'll have to investigate if I can change that, it would reduce network traffic), but can't change frequencies unless they had the admin account & password.
I haven't tested RDS yet, so that is on the list. It will do it (as well as demodulate CW and other data modes).
I've still got to include the station logo and a bit more info.
But it works well. The issue was that the RTL-SDR V4 was not supported - the V3 worked fine the first time I tried it (well, almost the first time, I had to reinstall drivers and then rebind the driver to the Microsoft WSL virtual environment so the Docker container could see it.
I will publish a (hopefully) easy set of documentation that can be used to duplicate what I did. It should also work with the SDRPlay and other supported SDR's (you'd have to look at the supported hardware to get a full list).
Some downsides. The software will only output in mono. Not such a big thing for radio broadcasts intended for the AM band, and not big for Artisan Radio either, since that is our broadcast mode as well.
The default visuals are not exactly awe inspiring. I'm going to have to play around with them, as there's a lot of available customization re colors, opacity of menus, etc. But you have to remember you are running inside a browser, not a custom program with a custom user interface.
The Docker image is the best way to install the software on a PC. An image is also available for the Raspberry PI, but since I don't have one, I couldn't test that. I could not get either the OpenWebRX or OpenWebRX+ software to install on Linux. I know you can't expect support on Open Source Software, but I'd at least expect that the developers would ensure that the documentation and repositories were up to date, and working. Even getting the Docker image working was difficult. Part, admittedly, was my rustiness with Linux/WSL and lack of familiarity with Docker, but part was just poor documentation. I actually had to download additional software to get the RTL-SDR V3 dongle accessible from within a Docker container (search engines are your friend, I use Duck Duck Go).
I'll also publish the URL for the receiver once I'm confident it's not going to be going up and down frequently, likely in a day or two.
Well, first of all I screwed up and managed to delete all my OpenWebRX+ configuration changes. I think I know how I did it, but before I publish the documentation, I need to make sure.
In the meantime, I've also been experimenting with the software.
Most of the networking data use comes from the audio link between the server and the client browser. Around 195kbps. The software uses WebAudio, which I think uses PCM - that's why the stream is so big. They do use some form of compression, but it's still huge.
The rest of the data is taken up with UI elements, specifically the waterfall display. Unfortunately, you can't turn it off in the distributed software. I found someone who had made a modification to do this, but in light of the difficulties I've had getting even the distributed software working, I passed.
Anyway, I took the update rate down of the waterfall display from 9 lines/second to 3 lines/second, and managed to chop 100kbps off the network use. The display is still acceptable, and the overall network throughput is about 245kbps (down from about 345-350kbps). It's not going to get much smaller due to the audio bitrate.
Still, if you even have a slow upload rate of 3-5 Mbps, you should be able to support at least 10-15 listeners. Far more than I anticipate I'd ever get.
I also found out that the user is able to change almost anything visual within the current listening profile, including the frequency. They can't change the band width or any other receiver settings without an admin ID and password. I'm going to set up a single profile, RTL-SDR Artisan Radio, that has a 1Mhz bandwidth, with Artisan Radio centered, and the tuning starting there. There are no other listenable stations within that 1Mhz of spectrum, particularly since the SDR has an untuned rubber duck antenna. The server computer with the SDR sits about 6 feet away from the Decade MS-100 transmitter.
The RTL-SDR is ideal for my purposes. It supports listening up to a 2Mhz chunk of radio spectrum. The SDRPlay is a much better general purpose SDR, as it supports up to 10Mhz. But according to reviews that I've read, some like the RTL, some like the SDRPlay - it seems to be a wash in terms of overall actual useage.
I was also using OpenWebRX+ as a simple spectrum analyzer. There is a noticeable visual difference in the signals between the Decade MS-100 and a Whole House 3 I had lying around and set up quickly. While both are certified, the Whole House 3 did generate a lot of low level, spurious signals. I haven't looked at the infamous 2nd and further out harmonics of it yet.
Here is the link to the test server.
I've only enabled 2 clients, one of which I will be using for testing.
I've confirmed how I accidently deleted the configuration. One of the last things remaining before I release this and put it on my web page is RDS - I can't seem to figure out how to enable it (if indeed it isn't automatic, which the documentation implies it might be).
If you're interested, give it a gander. I've tested it on the Vivaldi and Edge browsers. It should work on pretty much anything.
Addendum. I think the RDS data is supposed to go into what is showing up as an empty box on the bottom left of the waterfall display. I'm pretty sure that I am transmitting the RDS data, but will be testing that out in my car tomorrow. It's funny how problems keep cascading...
Further Addendum. I was right. That's where RDS data goes, and it's there now. I'll keep the server running in test mode for the next 24 hours or so, hopefully get some feedback, and then put it live on my website.
Problem with high audio frequencies.
We've already talked about distortion of sibilant frequencies in speech and music but it has not yet been solved for the Artisan Radio SDR.
This morning I listened to 'Oompah Hour' and heard some especially bad distortion up on the range of the pre and de-emphasis.
It sounds like either the audio is being double pre-emphasized or not properly de-emphasized.
The problem is not often affecting the old-time jazz because those audiofiles contain few very high frequencies, except occasional muted trumpets which tear up.
There may be a problem with double pre-emphasis that is only showing up a lot in certain shows. I've changed something in my audio chain (not in the SDR) and we'll see if it improves things, particularly in the jazz trumpet area (which should not be happening). All the music we play in The Best Jazz, Lost Jukebox and Teenage Dreams is preprocessed, normalized and should not have any issues.
I've done some audio reprocessing on some of the third party shows we carry to see if I can improve things. The Oompah Hour in particular is recorded so that the sound is almost continuously pegged at 0db (the waveform, if you can call it that, in Audacity is just solid blue). Maybe that's standard, I don't know, I'm not a sound engineer. Normalization helps make it sound better on the station, but unfortunately some of the sibilance you're noticing in the vocals appears to be in the recording itself.
I may have to experiment with some form of de-essing. Although it could be that I'm doing something else wrong. I could use some help here.
I think I may have found most of the problem. It appears that the software I modified to add in RDS defaulted to adding pre-emphasis as well. The transmitter is also adding pre-emphasis (I believe). The receiver takes one of those away, but leaves the other, so it was getting boosted highs.
I've just finished listening to the Oompah Hour and I'm not hearing much if any sibilance with it normalized to -2db. In fact, it sounds really clean.
I'll wait for those with perhaps better ears than mine to comment.
Happy to hear that the audio mystery is getting solved.
Before I knew that you may have discovered the cause of the problem I downloaded an 'Oompah Hour' and analyzed its audio properties.
It was perfectly maximized to dominate the entire digital envelope without any clipping and had just enough compression to keep the level from drooping, thus maintaining enough dynamic range to prevent it from sounding too smashed.
I thought it was technically perfect, and no wonder, since it is produced by Tim in Bovey, chief engineer of 3 full power stations, builder of his own home studio and part 15 radio station.
Thanks for the suggestion that the sibilance problem might be in the pre-emphasis/de-emphasis realm.
That's what I enjoy about Part 15 broadcasting. I've never made any bones about being a sound engineer, and I learn something pretty much every day listening to those who are in the know, and chasing down issues.
That being said, I personally prefer sound that's less compressed and a little less loud, which I find a bit easier to listen to over long stretches. I do love the Oompah show though (I wouldn't be carrying it otherwise).
I tuned into the Artisan SDR this morning and the audio sounded right, so it appears that whatever was at fault has been remedied. I heard a guest DJ hosting a music show and all sibilants were well defined but never over-modulated.