• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Support for Botic Linux driver

Jriver & Jremote with BBB & Botic driver.

Hi Guys,

Probably a little off topic but still relevant to BBB and Botic driver. For those are missing the user friendly of the Jriver & JRemote interface, now you can have it back with BBB and Botic driver without compromise the SQ! I've great result after following the link from this page

I have Jremote on my iPad to navigate JRiver on another pc/laptop. Jriver is wirelessly control my NAS which has builtin Media player. All data are sent to BBB via LAN from Router (if any one knows how to setup wireless dongle on BBB, please share). MPD on BBB sent i2s to DAC via Botic driver.

Below are the summary of what I have done;

1. Installing upmpdcli on the Pi to provide an UPnP interface
Edit/create /etc/apt/sources.list.d/upmpdcli.list and add the following lines:
deb Index of /upmpdcli/downloads/debian unstable main
deb-src Index of /upmpdcli/downloads/debian unstable main
Issue the following commands from a terminal to install upmpdcli:
sudo apt-get update
sudo apt-get install upmpdcli

2.MPD-UPNP versions
The code for the UPNP plugin has been integrated into the master MPD git source. It is not part of regular MPD 0.18 versions (at least up to 0.18.9), you will have to retrieve the code from the git master branch to get it. Once this is done, the instructions for configuring, building, and installing are the same as those which follow, and were written for the original plugin addition.
Retrieving the source code for the original patch
The plugin exists in a github repository. To check it out:
git clone https://github.com/medoc92/mpd-upnp.git mpd-upnp
cd mpd-upnp
git checkout -b upnp origin/upnp

3. Change the following lines:
music_directory "/net/servername/path/to/music"
bind_to_address "any"

mixer_type "disable"

Reboot BBB.

Hope it works for you too!
Chanh
 
Hi Guys,

Probably a little off topic but still relevant to BBB and Botic driver. For those are missing the user friendly of the Jriver & JRemote interface, now you can have it back ............

Nice setup, but complicates things a little bit too much just to use remote/another client (another computer running jriver and an upnp server), imo it renders useless the simplicity of mpd architecture.
 
Nice setup, but complicates things a little bit too much just to use remote/another client (another computer running jriver and an upnp server), imo it renders useless the simplicity of mpd architecture.
I hear you! Assumed you have not yet experience with Jremote?
Do you have a better idea in navigate/managing a moderate 4TB library with MPD? Personally, tried virtually everything, and MPAD, MDroid,...., and LMS, they simply didn't cut it? ;):rolleyes::rolleyes:
 
Probably a little off topic but still relevant to BBB and Botic driver. For those are missing the user friendly of the Jriver & JRemote interface, now you can have it back with BBB and Botic driver without compromise the SQ! I've great result after following the link from this page

I have Jremote on my iPad to navigate JRiver on another pc/laptop. Jriver is wirelessly control my NAS which has builtin Media player. All data are sent to BBB via LAN from Router (if any one knows how to setup wireless dongle on BBB, please share). MPD on BBB sent i2s to DAC via Botic driver.

Hi Chanh.

I have been using UPnP connectivity for a while and have a very convenient easy to use setup without the complication you describe. You don't really need the JRiver stuff (unless you really want or need all of the DSP stuff?). If your NAS has UPnP media server functionality and your BBB has UPnP media renderer functionality all you need is a media controller on a tablet or smartphone to join it all together. I have Android devices and use the BubbleUPnP app as my media controller. As you're an Apple User check out the PlugPlayer app.

Although UPnP is a layer on top of mpd the advantage is that the same media controller interface is used throughout the household, for example to play music in the television room I just select the AV amp as the renderer on my smartphone and everything else works the same. That's important to me as my lady is a bit of a technophobe.

Ray
 
Last edited:
Just for completeness (and I've linked to this previously), I use gmediarenderer to add UPnP functionality to my 'miero' BBB; it worked well on the previous version of miero's driver and I'm planning to upgrade to the latest version and reinstall gmediarenderer shortly.

Here's a link to the instructions;

Playing music on a Raspberry Pi using UPnP and DLNA (v3) | Stephen C Phillips

Although the article is aimed at RPi devices gmediarenderer is built on Debian, the same as miero's driver and, as I said above, it installed and worked on my BBB.

Ray
 
Hi Ray,

Thanks for the comprehensive input. I have also tried your recommended route but still found JRemote more user friendly.
Right now I have Win-Server 2012 at core mode with JService (Jriver without GUI) running in the background as DLNA server/controller. Database is now relocated into an external USB docking 2x1TB SSD. With this setup, I able to retain both great user interface and the wonderful Sound Quality. I now have removed the NAS in stereo/hifichain, and only use it for Home Threater movies and background music with UPNP interface.

Cheers.
Chanh
 
nautibuoy, because output pins on the BBB have to be switched ... DAC is able to receive data on same pins, but BBB is not able to generate both I2S and DSD on same pins.

Here is the scheme:
I2S: (BCLK) (LRCK) (DATA1) (DATA2) (DATA3) (DATA4) ... 2 channels in each data pin
DSD: (BCLK) (DATA1) (DATA2) (DATA3) (DATA4) ... 1 channel in each data pin

Hi miero, sorry to be a bit like a dog with a bone...

I've been reading through the config settings for your driver on your download site. Am I right in thinking that the I2S/DSD pin mapping issue is actually a limitation of mcasp rather than the BBB hardware per se?

Ray
 
Hi Guys,

Probably a little off topic but still relevant to BBB and Botic driver. For those are missing the user friendly of the Jriver & JRemote interface, now you can have it back with BBB and Botic driver without compromise the SQ! I've great result after following the link from this page

I have Jremote on my iPad to navigate JRiver on another pc/laptop. Jriver is wirelessly control my NAS which has builtin Media player. All data are sent to BBB via LAN from Router (if any one knows how to setup wireless dongle on BBB, please share). MPD on BBB sent i2s to DAC via Botic driver.

Below are the summary of what I have done;

1. Installing upmpdcli on the Pi to provide an UPnP interface
Edit/create /etc/apt/sources.list.d/upmpdcli.list and add the following lines:
deb Index of /upmpdcli/downloads/debian unstable main
deb-src Index of /upmpdcli/downloads/debian unstable main
Issue the following commands from a terminal to install upmpdcli:
sudo apt-get update
sudo apt-get install upmpdcli

2.MPD-UPNP versions
The code for the UPNP plugin has been integrated into the master MPD git source. It is not part of regular MPD 0.18 versions (at least up to 0.18.9), you will have to retrieve the code from the git master branch to get it. Once this is done, the instructions for configuring, building, and installing are the same as those which follow, and were written for the original plugin addition.
Retrieving the source code for the original patch
The plugin exists in a github repository. To check it out:
git clone https://github.com/medoc92/mpd-upnp.git mpd-upnp
cd mpd-upnp
git checkout -b upnp origin/upnp

3. Change the following lines:
music_directory "/net/servername/path/to/music"
bind_to_address "any"

mixer_type "disable"

Reboot BBB.

Hope it works for you too!
Chanh

Hi,

Just for your information, you do not need step 2 for controlling MPD from an UPnP control point. The MPD UPnP plugin and upmpdcli are not incompatible, but using them both does not make much sense, except if you want to use both MPD and UPnP clients (remotes) using the same data from an UPnP Media Server, which would be really uncommon. From an answer in the discussion at the bottom of the upmpdcli home page:

With the client plugin (MPD-UPNP), the integration happens "behind" mpd, and you use an mpd client like MPDroid.
With upmpdcli, the integration happens "in front of" mpd, and you use an UPnP control point like Bubble UPnP.

Both approaches allow playing music stored on an UPnP Media Server with MPD. Choosing is mostly a question of knowing which user interface you prefer (I prefer the UPnP clients), and what other devices you have on the network.

Technically, the two packages (even the initial implementation of the plugin) share very little code beyond low level UPnP helper code (and libupnp of course). One (MPD-UPNP) behaves mostly like an UPnP Control Point , the other (upmpdcli) is a UPnP Device.
 
nautibuoy: Ah, plain but difficult question at the same time .... here is my best guess to explain the issue:

I'd rather say it caused by design choice of some DAC designers... to multiplex I2S and DSD support into single chip they reused clock pin (LRCK) to carry audio data ... digital sources usually separates pin to clock pins and data pins ... but in DAC like ES9018 (and others) those pins are mixed together (rerouted inside a chip).

But it's non-compatibility on both sides:
- DAC designers saves 1 pin by multiplexing I2S LRCK signal with DSD DATA1
- CPU designers saves internal circuitry by not allowing to route LRCK and DATA signal to same pin.
 
Hi,

Just for your information, you do not need step 2 for controlling MPD from an UPnP control point. The MPD UPnP plugin and upmpdcli are not incompatible, but using them both does not make much sense,...

Thanks JF! Haha.. Clearly showed my poor knowledge in Linux...! Right now JRiver play file via UpMPD player. Can I assume that it is your upmpdcli? If so the sound quality is awesome, virtually the same quality to MPD direct or RuneAudio but with much greater flexibility/user friendly interface. Love it!
Will try redo the image again! The appropriate methodology.

Thanks again to Miero & JF.
Chanh
 
Not quite so, there is a pin Multiplexer - Wikipedia, the free encyclopedia between McASP and actual AM3358 processor pin... :)

<an enthusiastic pupil at the back of the class thrusts his hand in the air>

Yes but, yes but...

...a mux/demux pair are a means of efficiently getting multiple data streams from A to B but they shouldn't be transforming the data in any way? Although the pair is a physical element it should be invisible in the logical data flow map.

The mcasp config settings appear to be where the assignment of gpio pins to each data stream takes place? Why would you do that if the assignment were subsequently changed by the mux?

The issue seems to be that mcasp treats clock data as a 'special' case, reserving gpio pins for it. That's not an issue with BCK as both PCM and DSD utilise BCK. The stumbling block seems to be LRCK. If the clock and audio data were just treated as data streams by mcasp, with gpio pins assigned serially depending on whether the audio data is PCM or DSD format the issue goes away.

Simplistically:

GPIO Pin #1 >>> BCK (DSD) >>> BCK (PCM)
GPIO Pin #2 >>> DATA1 (DSD) >>> LRCK (PCM)
GPIO Pin #3 >>> DATA2 (DSD) >>> DATA1&2 (PCM)
GPIO Pin #4 >>> DATA3 (DSD) >>> DATA3&4 (PCM)
GPIO Pin #5 >>> DATA4 (DSD) >>> DATA5&6 (PCM)
GPIO Pin #6 >>> unused (DSD) >>> DATA7&8 (PCM)

Doesn't it come down to whether mcasp could be changed to that model?

I realise that is an easy question to ask but openly admit I have little idea about the issues that might be involved, such as intellectual rights (is mcasp open source or proprietary?), or Linux etiquette, let alone the technical aspects, which would appear to require deep programming skills far beyond my own (I used to be paid to program in Cobol and Fortran but recognise that makes me something of a fossil).

Thanks; I await my next lesson

Ray
 
nautibuoy: unfortunately, this is not possible...

If you peek inside the "AM335x SitaraTM Processors" manual named sprs717g.pdf, you will find that it is not possible on any am335x processor.

The mcasp0_fsx does not have common pin with any mcasp0_ax? pin. Same applies to second mcasp1 channel.
 

Attachments

  • am335x-mcasp-pins-small.jpg
    am335x-mcasp-pins-small.jpg
    48 KB · Views: 388
nautibuoy: unfortunately, this is not possible...

If you peek inside the "AM335x SitaraTM Processors" manual named sprs717g.pdf, you will find that it is not possible on any am335x processor.

The mcasp0_fsx does not have common pin with any mcasp0_ax? pin. Same applies to second mcasp1 channel.

Ah! so it is in fact a constraint of the BBB hardware after all (or more likely the firmware of the processor).

So, if it isn't possible to utilise the native hardware layer the next question is whether a work around is possible.

I know you've done some good work on detecting the native sampling rate of the audio data and arranging for the clock speed to be switched on the fly to preserve the native sampling rate. I also know that you are detecting whether the audio data is PCM or DSD format. With that in mind, would it be possible, within your driver, to remap the gpio pin assignments on the fly, depending on whether the audio data is PCM or DSD or is enacting the mcasp configuration file a 'done once at startup' action?

Remapping the pins on the fly is essentially all the Botic PCM/DSD switch is doing, based on information that is passed to it from the BBB. Can you pull that back to be a driver function?

Sorry to labour this, as I said, I don't even have any DSD files, but I would really like to bottom this out and I'm sure many others would find it useful. It's also good to exercise one's mind on these sort of puzzles.

Perhaps I should shut up now.

Ray
 
nautibuoy: aren't you really trying to reinvent "the wheel"? :)

there is no autodetection for sampling rate or audio data format ...

the audio driver knows exactly what it is playing and it toggles GPIO signals for EXTERNAL clock selection and i2s/dsd routing

the external switches on botic board is exactly that workaround you are looking for, but it was already designed months ago :)

Or have I missed something? :)

Notice: couple of free hires recordings (including the DSD) are available at High Resolution Music DOWNLOAD services .:. FLAC in free TEST BENCH
 
nautibuoy: aren't you really trying to reinvent "the wheel"? :)

Sorry, no just wondering if an improved wheel is possible. A solution contained on the BBB would be so much more elegant than one needing external matrix switching, in the same way that the Edel Network Media Renderer does (at a price), for example.

Anyway, I risk becoming an annoying bore (if I'm not already:)) so I'll let it go now.

Thanks for your patience and your ongoing work on the driver.

Cheers

Ray
 
Just for your information, you do not need step 2 for controlling MPD from an UPnP control point. The MPD UPnP plugin and upmpdcli are not incompatible, but using them both does not make much sense, except if you want to use both MPD and UPnP clients (remotes) using the same data from an UPnP Media Server, which would be really uncommon. From an answer in the discussion at the bottom of the upmpdcli home page:

Thanks for this medoc92. I've just installed upmpdcli on my BBB over a fresh install of the miero distribution and encountered no problems. The BBB now appears on my Bubble UPnP controller and seems to function correctly. The only problem is that I don't currently have a DAC hooked up to my BBB so can't actually listen to check if all is well but, from the activity on the BBB LEDs, it appears to be busy when it is supposed to be playing a track.

Ray