DAB integration?

Dohmar

hondagx35 wroteHi Dohmar,

http://i65.tinypic.com/1scrvt.jpg
On Firefox it is easy to zoom in and out with the scroll wheel from your mouse.
CTRL + scroll.

I have an overall change to the GUI as it stands to present the user interface more like a typical hardware design (using the perks of a nice touchscreen lcd) while still remaining easy to use and configurable.-
At the moment there will be no change in the UI.
So let us do the integration on a separate page, you can change this later on.

Frank

Thanks! I've done that on my PC and the interface is much better! I do have other suggestions in regards to layering and declutterring but have already posted those in other threads

-D

daviestar

Bear with me, I'm buying all the necessary hardware to get Rune Audio set up, new to RPI

Which RPI do you guys recommend? Will using an RPI3 unnecessarily complicate things (as 64-bit)? From my 'carputer' perspective, the extra power, and maybe not needing to power an external USB hub, is a plus.. but can easily work around it.

Once I'm up and running and figure out how get in and hack RuneUI, I'd suggest working towards a simple 'Hello World' view, where we can type in the FM frequency to an <input> and stream the audio from that frequency.. thoughts? Or if DAB would be a better starting point, type in the name of the DAB station to grab the correct stream.

If we can get to this point, we should be in good place

Dohmar

RPI3 is the logical choice. It might not be 100% supported NOW but it will be.
Power is not an issue as the CPU scales its power determined by its load
Frank has already got FM working via command line for simple FM presets, its now a matter of extending that call and adding user interface stuff lime a freq search.

-D

daviestar

Hey guys, quick update. I started playing with the RPI3 last night.

Rune was utterly painless to get up and running following the quick start guide! Everything worked first time, and I got tracks playing through the headphone jack. I did a little digging, ssh'ing and console logging.

Next time I get a chance I'll Fork the RuneUI repository and figure out the best way to hack into the RPI3 live. Currently planning to add a bash script to Grunt which will deploy the assets after pre-compiling using ssh + rsync to /var/www on the pi.. does this sound like the best approach?

After this, I'll try to get the FM radio working as Frank has on the RTL2832U + R820T2.

Here's a brain dump of questions/thoughts:

@[deleted] / Dohmar can we start compiling a list of the parameters to pass between frontend and tuner, and the format of the values needed ie.

fm_freq=96.9
dab_stationname=bbc_radio6

It'd be good to use this as a Spec for the frontend/MPD communication I can start with.

Dohmar wrote Middle pane - View 2- Would have an option to do a scan, where the unit scans the frequencies (and lets say, 88Mhz to 108mhz) then analyze the peaks vs the troughs and report the frequency of those spikes as a menuitem.

Is this type of scan built into the tuner or are we going to have to make it?

Cheers

Dohmar

I'm really not sure. On SDR-J, the guy who wrote it runs the backend on his raspberry pi headless, and runs a frontend with a gui on another machine. I think we'll probably have to get someone to write a command line frontend to the pi's backend, and I'm no coder and have no idea about that stuff. I would suggest that the SDR-J software would contain the code required to pass to the backend daemon. I have no idea how it would work thought, its a little bit beyond me.

I think the other items you'll need are
SampleRate=2000000
BitRate=?

Re tuning - there are command line scripts on rtl-sdr's main site that scan a set frequency and then generate histograms that show the signal strength - the histograms are generated from a csv file that the command line tool spits out. You can set the granularity of the scan as fine or as wide as you want - In the case of consumer radio you'd want to do a scan thats thorough enough to reliably be able to locate radio stations but not so long the user will get bored (ie I ran a scan for an hour and it generated a rather large csv). In the case of live software I think you could probably pipe the output to grep or some other parsing software and the spit out the radio stations.

-D

daviestar

Hey folks, I installed rtl-sdr with:

pacman -Sy rtl-sdr

After a little debugging I've been able to get a sound output with:

rtl_fm -f 99.5e6 -M wbfm -s 200000 -r 192000 - | aplay -D hw:0 -c 2 -r 48k -f S16_LE

But my output is really weird and sounds slowed down!! Not sure what's going on

This is on vanilla install of Rune on RPI3 outputting to headphone jack until my Digi+ arrives.

Almost up to speed with you guys, and will make a start on the UI later tonight.

Cheers.

Dohmar

The sample rate on the onboard hardware is much slower than a dac hat. You'll need to reduce the sample rate section of the command line. Its getting fed too many samples and is playing them as fast as it can but it cant keep up.

-D

daviestar

Thanks, this worked:

rtl_fm -f 99.5e6 -M wbfm -s 200000 -r 96000 - | aplay -D hw:0 -c 2 -r 48k -f S16_LE

Dohmar

Just a thought, but you might be able to quiz the RuneOS for what audio device is selected in the MPD config screen and then base the sample rate variable upon that. Ie is IQdacPI+ is selected, default to 192000, if its the onboard audio either 3.5mm or HDMI then you use 96000

-D

daviestar

Dohmar wroteI've received some build instructions from the guy who writes sdr-j, so if I can compile that I should theoretically be able to do the same with DAB

Could you please post these build instructions?

Dohmar wroteNot sure if its stereo, my speakers are currently close together - any way to verify? Can we pipe the audio to a command line 2 channel mixer to check it out?

Using the play command (sox) you can output a basic 2 channel display:

rtl_fm -f 99.5e6 -M wbfm -s 200k -r 96k | play -r 96k -t raw -e s -b 16 -c 1 -V1 -

http://sox.sourceforge.net/sox.html

Dohmar

Here it is, cut and pasted from his email - (his name is Jan Van Katwijk and hes very helpful)
-----------------------
In order to be able to compile you would need
Qt (either Qt4 or 5)
fftw3
sndfile
faad
portaudio
All libraries are available under Arch.
Qt is essential, it shows a.o. the name of the ensemble and the stations within an ensemble,
so you will have some form of GUI. Selection of programs is also on the GUI.

Once the "environment" is complete, it is time to look at the file "dab-rpi.pro", the configuration file
for use with the qt make facility
CONFIG += NO_SSE_SUPPORT
indicates that you do not have SSE instructions as on the PC. You best comment the two lines
as here
#DEFINES += SIMPLE_SYNCHRONIZATION
#DEFINES += FULL_CORRELATION
The main choices are to be made in the section labeled "unix"
unix {
#CONFIG += dabstick_osmo
CONFIG += dabstick_new
CONFIG += sdrplay
CONFIG += rtl_tcp
CONFIG += airspy
#CONFIG += airspy-exp
#CONFIG += tcp-streamer # use for remote listening
#CONFIG += rtp-streamer # remote using rtp (very immature)
CONFIG += gui_1
DEFINES += MOT_BASICS__ # use at your own risk
DEFINES += MSC_DATA__ # use at your own risk
DESTDIR = ./linux-bin
INCLUDEPATH += /usr/local/include
LIBS += -lfftw3f -lusb-1.0 -ldl #
LIBS += -lportaudio
LIBS += -lsndfile
LIBS += -lfaad
}

If you have a dabstick with the regular arch packes loaded, uncomment
CONFIG += dabstick_osmo
#CONFIG += dabstick_new
#CONFIG += sdrplay
#CONFIG += rtl_tcp
#CONFIG += airspy
#CONFIG += airspy-exp
the line for dabstick_osmo and comment out all the other lines for devices
If you want to use the RPI as audio device, comment out the line
#CONFIG += tcp-streamer # use for remote listening
If this line is uncommented, the output will be sent to port 20040, a simple "listener" program
that you can then use on a WiFi network is part of the sources (sound-client).

The latest version of the software has a line
#CONFIG += rtp-streamer # remote using rtp (very immature)
which can be commented out, since it is merely experimental and not complete
(and there is no how-to for it)

DEFINES += MOT_BASICS__ # use at your own risk
DEFINES += MSC_DATA__ # use at your own risk
These two lines can be commented out. If uncommented you might see some data appearing on the GUI,
depending on the station selected.

If that is all done, you can check whether the include file(s) for the dabstick are in /usr/local/include or something like that.
Then all is about ready to go:
For qt4 (which I have on my RPI)
qmake-qt4
make
does the trick
With some systems qmake is just called qmake, sometimes qmake-qt4 and for qt5 it might be named qt5
I know of some other people that are running jessie on the RPI3 that everything works smoothly, on my Arch
RPI it compiles and runs without problems, so there is hope.
------------------------------

He also said ;
"I am running my RPI headless - it is on a different floor than where I normally am, I am using a SSH connection for the control, and I am using its "server" function to listen". So perhaps we don't need to reinvent the wheel, only modify it somewhat...

-D

hondagx35

Hi Dohmar,

Qt is essential, it shows a.o. the name of the ensemble and the stations within an ensemble,

This is our problem with this software, because we need a command line interface or a linux socket connection (like mpd).

I made some tests and i'm absolutely disappointed by the sound quality you get from DAB.

Frank

daviestar

Hi Frank,

Question blast:

Did you manage to get a working version of DAB-RPI?

Did you use the TCP_STREAMER it comes with?

What was the bitrate of the stations you tried?

Do you think the sound quality is bad because of the bitrate, or the software decoding?

Any pointers would be great

Dave

Dohmar

Hi Frank,
Are we talking DAB or DAB+, given they're separate formats?
DAB/DAB+ has very limited range, it tends to fall off very quickly at the outer extremities of the range.
FM will doubtless sound poor for the most part, but DAB should be able to get decent bitrates. Though that is very much dependant on your station
Ie in Aus, the one DAB+ station I really want is Double J, according to this wikipedia article, they transmit at 80kbps, which isnt bad
https://en.wikipedia.org/wiki/Digital_radio_in_Australia

Way better than FM, WAY WAY better than AM but there is always a tradeoff for radiowaves, the higher the frequency, the more bandwidth you have but the more the radiowave is affected by hills and RF and all that stuff. AM radio sounds like crap but you can tune in to it wherever you are, same with global shortwave (which incidentally, if we can get this tuner and interface thing worked out, we could pick up Shortwave, AM, FM, UHF (CB), VHF (Marine), DAB, DAB+, transponders from aircraft, communications from the international space station etc. SDR is incredibly powerful, if only we could harness that versatility... (heaps of effort though)...

-D

daviestar

BBC here in the UK is slightly better, but have to say I'm still surprised by the low quality:
https://en.wikipedia.org/wiki/BBC_National_DAB

They provide .m3u8 streams for these same broadcasts over the internet at 320kbps:
#54622

I'm beginning to realise why there is so little interest in DAB+

Unfortunately my favourite station, and more importantly my partners favourite station, is BBC 6music - only available as DAB+.

Dohmar

I suppose we should maybe categorize hifi and lofi separately.

LOFI - SW/AM/FM/DAB/DAB+/UHF/VHF/ISS/custom? (because naturally, radio waves are limited by bandwidth and historically tuners haven't had the bandwidth to represent a radio stream accurately)

HIFI - SACD, FLAC, 24 bit RAW pipe, 32 bit analogue unbalanced RCA in, etc

Add yours...?

-D

daviestar

My music library is all FLAC and AAC from Mac Mini to Arcam irDAC via USB at 192kHz, to AVI Integrated amp to, ATC SCM11's

Trying to recreate at least some of that quality in-car (including DAB) is proving near-impossible. Was thinking about saving for one of these and taking it apart (which might be a crime!) to integrate with the car and RPI3: http://chordelectronics.co.uk/mojo/

Now thinking I might be better with a conventional, decent head unit (like this) with a plug in DAB (like this). It provides it's own cheap DAC but who cares when the quality is so low the begin with?

It's a shame, as Rune presents a fantastic solution for in-car - you get to control it with your phone, which for me is usually mounted on the dash anyway for Maps. Running in PHP and JS, for me is huge as that's what I get paid to do all day

It adds a twist to the current trend in car audio of iPads playing tunes wirelessly to an Airport with Optical out, and instead you control it wirelessly, but have total control over how the sound it output, wired, to your DAC/DSP/amplifiers.

If you guys are still hoping for FM/AM compatibility with Rune and RTL2832U + R820T2, I'm happy to help and am confident I can make a sweet UI for it, but I'd need more backend assistance, as it's not something I'd personally use. Compiling code is not something I know anything about, and documentation for these packages is scarce at best.

Dohmar

I really want to see this happen, a good RTL-SDR platform is yet to be made, at least in terms that a normal consumer can take advantage of.

My music library is all flac, and a good portion of that is 24 bit vinyl rips, but that said, radio is a vital part of a hi fi, a radio is a communications device and not just a music player, and we should (if we;re gonna attempt it) do it right so that i might be able to build my little pi-fi and take it out into the country with a big antenna and a solar panel and be able to keep informed (extreme scenario, but i AM making my pi fi based around a 12v in for a reason...)

-D

Edit - Also will add, that as an audiophile that spent a lot of money on car audio - just dont. The road noise, ambient traffic and engine noise will cancel out any harmonics you might be able to appreciate. get a simple pioneer or clarion or sony with a good signal to noise ratio and accept that a car is not a good platform for audiophiles.

Dohmar

daviestar wroteIf you guys are still hoping for FM/AM compatibility with Rune and RTL2832U + R820T2, I'm happy to help and am confident I can make a sweet UI for it, but I'd need more backend assistance, as it's not something I'd personally use. Compiling code is not something I know anything about, and documentation for these packages is scarce at best.

I think this is my major wish. I have a fair confidence that I can implement the optical drive stuff myself (perhaps not GUI) but I can submit those things to the coders and let them improve on it

AM is a hallmark of the 20's to 80's, FM the 70's to the present day, and DAB/DAB+ 2012 or thereabouts to whenever...

Since SDR does all of those, plus more, one single versatile UI plus a backend would seem to do the job... at least thats my laymans assumption

-D

Edit - And if you could tweak a GPIO port to run a gauge like attached, that would be an insanely great addition.

daviestar

You based somewhere remote in Australia? I spent 8 months in Melbourne a couple years ago on a round-the-world trip and had a great time

Spent 6 months in the outback too when I was a teenager!

If you're looking to tinker with this till it works, here are some pointers:

SSH into the RPI3 and cd /var/www to mess with PHP/JS, set app/config/config.php $devmode to true so you can edit the JS in place.

In theory, you should be able to get it basically working through Rune with Franks command in this thread.

You can run shell commands with PHP using exec.

I'd recommend checking out the D3 library for Javascript. This is a popular library for crunching and displaying data in pretty much any way you can think of, with 1000s of demos you can hack to do your bidding. For example, this could form the basis for the scan you mentioned (both visually and mathematically): https://bl.ocks.org/efekarakus/cc7303456841523f37dd

You'll just need to figure out how to pump the data from the tuner into it.

PS. I agree with you to some extent about car audio

However I have spent a lot of time sound-proofing my car, and my theory is, since I know where me and my passengers ears are going to be (roughly) it should be possible to make something very very nice

Cheers.

« Previous Page Next Page »