piCorePlayer - DAB+ discussion

[toto]

https://github.com/hradio/omri-usb is a C library and JNI android library which is used by DAB-Z as middleware, I'm hoping that porting that to the pi isn't too difficult

Any success since then?
Thanks for any pointer to plain Linux SW to operate those USB DAB+ dongles (not SDR) that ship with Android app.

[bpa]

Switching on mobile hotspot every time I get in the car, or buying a GSM modem and separate sim card account don't seem like great options to me (or maybe I just like a challenge...).

I was thinking more about remote SIMs where the car "borrows" the phone SIM (i.e. no SIM in car) using Bluetooth and then the car can also provide a wifi hotspot within the car.

https://github.com/hradio/omri-usb is a C library and JNI android library which is used by DAB-Z as middleware, I'm hoping that porting that to the pi isn't too difficult, all the java stuff appears just to be wrapper code to the C functions.

OK - good there is open source application for dongle you have.
I think you should develop & test on a full Raspbian system - then recompile for PCP.

To interface with LMS - I think you should be aiming for a command line which can take parameters to tune
(i) if no audio stream then stream audio to STDOUT and feed into LMS.
(ii) if standard USB PCM audio stream - use arecord to capture and feed into LMS.
(iii) Leave metadata until tuning ans treaming audio is sorted. Metadata can be handled in many ways.

If there is a simple PCM audio interface then you'll be able to use "arecord" to test and check.

Check the USB device to see if there is a audio interface - use something like "lsusb -v -d 077d:627a"
Look in the output for "audio" interface that is "streaming". It'll also give the format such as PCM but possibly audio from DABmay not be decoded and may still be in AAC. The lsusb output will say what is supported.

Truncated output for a RadioShark USB which has AM/FM audio on audio streaming but tuning and LED control is through a HID.

Bus 003 Device 013: ID 077d:627a Griffin Technology Radio SHARK
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x077d Griffin Technology
  idProduct          0x627a Radio SHARK
  bcdDevice            0.10
  iManufacturer           1 Griffin Technology, Inc.
  iProduct                2 radioSHARK
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x00e3
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          3 F5 2006/04/27 17:50
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      1 Control Device
      bInterfaceProtocol      0 
      iInterface              0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength       0x001e
        bInCollection           1
        baInterfaceNr(0)        1
      AudioControl Interface Descriptor:
        bLength                12
        bDescriptorType        36
        bDescriptorSubtype      2 (INPUT_TERMINAL)
        bTerminalID             1
        wTerminalType      0x0601 Analog Connector
        bAssocTerminal          0
        bNrChannels             2
        wChannelConfig     0x0003
          Left Front (L)
          Right Front (R)
        iChannelNames           0 
        iTerminal               0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (OUTPUT_TERMINAL)
        bTerminalID            13
        wTerminalType      0x0101 USB Streaming
        bAssocTerminal          0
        bSourceID               1
        iTerminal               0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              0 
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink          13
        bDelay                  0 frames
        wFormatTag         0x0001 PCM
      AudioStreaming Interface Descriptor:
        bLength                14
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             1
        bSubframeSize           1
        bBitResolution          8
        bSamFreqType            0 Continuous
        tLowerSamFreq        6400
        tUpperSamFreq       48000
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0032  1x 50 bytes
        bInterval               1
        bRefresh                0
        bSynchAddress           0
        AudioStreaming Endpoint Descriptor:
          bLength                 7
          bDescriptorType        37
          bDescriptorSubtype      1 (EP_GENERAL)
          bmAttributes         0x01
            Sampling Frequency
          bLockDelayUnits         2 Decoded PCM samples
          wLockDelay         0x0001
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       2
      bNumEndpoints           1
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              0 
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink          13
        bDelay                  0 frames
        wFormatTag         0x0001 PCM
      AudioStreaming Interface Descriptor:
        bLength                14
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             1
        bSubframeSize           2
        bBitResolution         16
        bSamFreqType            0 Continuous
        tLowerSamFreq        6400
        tUpperSamFreq       48000
      Endpoint Descriptor:
        bLength                 9
.
.
.
.

[stevemartins]

While I can see the logic of in-car - just I find it hard to believe there are roads with a DAB+ signal and not a mobile one. It's just a word of caution as I think DAB+ may be hard work on a Raspberry Pi.

Rather than the undocumented USB adaptor you've got you may have better luck with a RTL-SDR (adaptors are quite cheap 10-20 £/$/€) as there is more open s/w available (e.g. https://github.com/AlbrechtL/welle.io ) but the downside as it is SDR (it can do any RF not just DAB) but it requires a good CPU but I believe it is ok on Pi3.

Switching on mobile hotspot every time I get in the car, or buying a GSM modem and separate sim card account don't seem like great options to me (or maybe I just like a challenge...).

https://github.com/hradio/omri-usb is a C library and JNI android library which is used by DAB-Z as middleware, I'm hoping that porting that to the pi isn't too difficult, all the java stuff appears just to be wrapper code to the C functions.

Steve

[bpa]

I'm building a piCorePlayer based in car entertainment platform, DAB radio would seem to be the right choice for in car, but happy to be corrected. I don't want to rely purely on a mobile wifi hotspot/on board music for my radio while driving.

I can see the device under /sys/bus/usb... and it identifies correctly under "description", has the control end point... I can't where to hook the audio from though. It's all just an idea at the minute.

While I can see the logic of in-car - just I find it hard to believe there are roads with a DAB+ signal and not a mobile one. It's just a word of caution as I think DAB+ may be hard work on a Raspberry Pi.

Rather than the undocumented USB adaptor you've got you may have better luck with a RTL-SDR (adaptors are quite cheap 10-20 £/$/€) as there is more open s/w available (e.g. https://github.com/AlbrechtL/welle.io ) but the downside as it is SDR (it can do any RF not just DAB) but it requires a good CPU but I believe it is ok on Pi3.

[stevemartins]

I'm building a piCorePlayer based in car entertainment platform, DAB radio would seem to be the right choice for in car, but happy to be corrected. I don't want to rely purely on a mobile wifi hotspot/on board music for my radio while driving.

I can see the device under /sys/bus/usb... and it identifies correctly under "description", has the control end point... I can't where to hook the audio from though. It's all just an idea at the minute.

[bpa]

A few years ago, I did a plugin for RadioShark (an AM/FM dongle) and it had no metadata.

A USB device may enumerate but does it provides access to the device controls.

For DAB+ support - you'll need access to an interface that provides (i) controls to tune (and maybe scan) (ii) audio and (iii) metadata

The standard USB may only provide audio- access to the other control may require a special support application. To work on pcp - this support application is best written in C and C++ (better still Perl but highly unlikely).

The basic question is why do you want to implement DAB+ ?
DAB+ is losing support because streaming radio over internet (whether wifi or mobile) is more attractive to broadcasters. In Ireland the DAB+ networks have shutdown because of the lack of growth/demand.

[stevemartins]

Hi,

I am interested in building in support for DAB+ dongles to piCorePlayer. I have looked at DAB-Z running on Pi with android omnirom and can get the dongle to tune in to DAB radio, so the hardware all works.

The DAB-Z implementation builds on OMRI from what I can tell (https://lab.irt.de/full-dab-support-...b-z-with-omri/), and the USB device enumerates on tinyCore.

I'm happy to do some of the coding and testing, but I would be interested is some assistance if anyone has any knowledge that could help implement this capability.

Please let me know your thoughts.

Thanks,

Steve