Hi Kai,
AFAIK, there are no Open Source drivers in Linux that support any of the DSP in ESS chips including hardware volume control.
Ask Audiophonics if their driver in Linux kernel supports Hardware volume control.
-Tim
Last edited:
It's only done to make the data easier to manipulate as computers don't operate natively at 24-bit. To grossly simplify things, imagine you had a number 123456, but the computer can only process data in chunks of 4 or 8 digits. To make the data align and make things easier you could add zeros in front of the number and store it as 00123456 (or 0012 and 3456). The actual data is never touched, and the zeros are ultimately discarded.
The Allo card respectively the card driver does the SPDIF conversion.
It's the same with a DAC - as a device. Even if e.g. an XMOS USB receiver would accept 32bit only, it doesn't mean that 32bit get fed to the DAC chip.
If the Allo device just accepts 32bit and there'd be a need to reduce the bitdepth then Allo would have to build that functionality into the driver and would have to make it accessible through Alsamixer.
Good luck.
Hi dear Friends!
I would like you to ask something:
I built a Raspi 2 B, with a Sabre 9083 DAC, (with analog power supply) and now i bought an old Radio, and in this oldie will i the Raspi music player build in - of course with a touchscreen!
Could you please help me wich touchscreen schould i buy (example from aliexpress or ebay) in 5", and how will it works together with moode?
Sorry but I noob for Raspi program-language.
Thank you any of your help!
Have a nice day!
I would like you to ask something:
I built a Raspi 2 B, with a Sabre 9083 DAC, (with analog power supply) and now i bought an old Radio, and in this oldie will i the Raspi music player build in - of course with a touchscreen!
Could you please help me wich touchscreen schould i buy (example from aliexpress or ebay) in 5", and how will it works together with moode?
Sorry but I noob for Raspi program-language.
Thank you any of your help!
Have a nice day!
Some words about ESS and their Sabre DACs.
ESS forces their customers to sign strict license agreements.
Neither showing documents about their DACs, nor showing internal functionality
through opensource drivers are accepted.
If you don't follow the rules, they shut you down.
The way around for manufacturers is to implement an MCU (micro computer) on the DAC board.
This MCU, which needs to be programmed as well, does the actual Sabre DAC control.
This way - and only this way - manufacturers will become ESS compliant.
On top of that, these manufacturers have to write and manage a OS driver that controls their MCU.
That's quite a job. And it's a propriatory project!!!
Obviously it's a huge effort to build a Sabre DAC board incl. SW.
Some of these chinese EBAY Sabre boards you might have seen, offer HW jumpers to control certain basic functions of their MCU/Sabre.
This way they get around writing a driver. Obviously that's the poor mans solution.
I've been playing around with the I-SABRE 9028 HAT from Audiophonics for a
while to do DSD-DOP testing.
The problem is, their driver is not really shaped up and it's not officially been made available.
They have quite a way to go to get that driver into the official RPI kernel.
I do know all that, because I'm in touch with their designers about it.
If you e.g. look at Allo in comparison. Allo is a huge step ahead. They learned their lessons.
I'm pretty sure Allo won't release their new Sabre 9038 HAT before the driver gets accepted by the RPI kernel folks.
They meanwhile know HW and SW must go hand in hand.
And meanwhile they should have also realized that OS maintainers prefer an officially accepted RPI driver over kernel-patch
solutions. Especially for license-critical stuff like Sabre DACs.
My advise: If you go for a rather sophisticated Sabre implementation make sure that a driver is available in the "official" RPI kernel!!!
And yep. SW volume control is one feature you'd be missing.
Actually the preliminary Audiophonics driver offers onboard volume control.
And that onboard VC even works on DSD-DOP!!!!
Basically I've been running squeezelite DSD-DOP DSD128 with the I-Sabre HW (it's actually software on the hardware) volume control feature.
Very nice, since DSD volume control can become quite a challenge. OK. For most of you. It's nice to have. 😉
Enjoy.
ESS forces their customers to sign strict license agreements.
Neither showing documents about their DACs, nor showing internal functionality
through opensource drivers are accepted.
If you don't follow the rules, they shut you down.
The way around for manufacturers is to implement an MCU (micro computer) on the DAC board.
This MCU, which needs to be programmed as well, does the actual Sabre DAC control.
This way - and only this way - manufacturers will become ESS compliant.
On top of that, these manufacturers have to write and manage a OS driver that controls their MCU.
That's quite a job. And it's a propriatory project!!!
Obviously it's a huge effort to build a Sabre DAC board incl. SW.
Some of these chinese EBAY Sabre boards you might have seen, offer HW jumpers to control certain basic functions of their MCU/Sabre.
This way they get around writing a driver. Obviously that's the poor mans solution.
I've been playing around with the I-SABRE 9028 HAT from Audiophonics for a
while to do DSD-DOP testing.
The problem is, their driver is not really shaped up and it's not officially been made available.
They have quite a way to go to get that driver into the official RPI kernel.
I do know all that, because I'm in touch with their designers about it.
If you e.g. look at Allo in comparison. Allo is a huge step ahead. They learned their lessons.
I'm pretty sure Allo won't release their new Sabre 9038 HAT before the driver gets accepted by the RPI kernel folks.
They meanwhile know HW and SW must go hand in hand.
And meanwhile they should have also realized that OS maintainers prefer an officially accepted RPI driver over kernel-patch
solutions. Especially for license-critical stuff like Sabre DACs.
My advise: If you go for a rather sophisticated Sabre implementation make sure that a driver is available in the "official" RPI kernel!!!
And yep. SW volume control is one feature you'd be missing.
Actually the preliminary Audiophonics driver offers onboard volume control.
And that onboard VC even works on DSD-DOP!!!!
Basically I've been running squeezelite DSD-DOP DSD128 with the I-Sabre HW (it's actually software on the hardware) volume control feature.
Very nice, since DSD volume control can become quite a challenge. OK. For most of you. It's nice to have. 😉
Enjoy.
Last edited:
Unless you need the extra precision of double floating point, the number doesn’t matter so much, but the speed of the Pi3 in floating point operations is significantly higher than previous boards.
They implement VFPv4 for the Pi3
Technologies | Floating Point – Arm Developer
There was talk of an automated build by Koda? Can someone post a link to it? I am wanting to try to build beta 9 so badly but don't know where to start! Thanks!
Rather late to the game so most of the issues sorted.
Did a Beta 9 build yesterday, so far so hunky dory.
I realise any comment I make may have already be covered but with the high post rate might be worth repeating.
The only comment I can make for new builders is beware of pasting too many lines at once if you feel the temptation, some commands seem to flush the keyboard buffer 'losing commands' after.
Obviously one command at a time is the safest 🙂 It seems to be fairly safe to copy sections of commands in blocks separated by the empty lines in Tim's build instruction list.
Things to be aware of any line that starts 'sudo apt-get install' will mean any further commands will be flushed and not be executed so these lines should be pasted into your terminal session on their own.
I goes without saying the commands that start 'sudo reboot' or 'sudo powerdown' will flush the command buffer 🙂
Did execute a 'sudo chmod 644 /etc/upmpdcli.conf' after the building this component.
Did a Beta 9 build yesterday, so far so hunky dory.
I realise any comment I make may have already be covered but with the high post rate might be worth repeating.
The only comment I can make for new builders is beware of pasting too many lines at once if you feel the temptation, some commands seem to flush the keyboard buffer 'losing commands' after.
Obviously one command at a time is the safest 🙂 It seems to be fairly safe to copy sections of commands in blocks separated by the empty lines in Tim's build instruction list.
Things to be aware of any line that starts 'sudo apt-get install' will mean any further commands will be flushed and not be executed so these lines should be pasted into your terminal session on their own.
I goes without saying the commands that start 'sudo reboot' or 'sudo powerdown' will flush the command buffer 🙂
Did execute a 'sudo chmod 644 /etc/upmpdcli.conf' after the building this component.
Sorry for not responding earlier but I wanted to do a build before confirming.
You will only see Tidal if you have more than one streaming service configured in Moode.
If you use Lumin there will be no Tidal button for you to to select but you will be able play Tidal tracks.
UPMPDCLI if it has Tidal ( or Qobuz/Gmusic) settings will generate a UPNP server interface into Tidal. What you need to do is select the library 'Moode UPNP-mediaserver' in the Lumin setup, there is the small issue of Lumin's stupid insistence on indexing the library itself so the first use there will be a delay. NB It does not index the whole of Tidal fortunately.
You do not need BubbleUPNP server, what this seems to do if used with Bubble control point is offload the Tidal/Qobuz auth from the control point to the bubble server. Upmpdcli does this as well by presenting a UPNP interface to a streaming service for standard UPNP control points.
The only time you will see Tidal is if you also have another streaming service configured whereupon you will get a folder for each streaming service.
Last edited:
Beta 9 feedback. I am running Beta9 on an rPi3 and 2. Both loose interaction of Playback and Browse tabs from time to time (once a dayish) requiring a reboot not just refresh.
I have Beta9 running on a ZeroW and a Pi2 and no probs
Noticed after an update it can take a while for the web management to populate with my radio stations.....
Talking of updates Beta 10 is up on Tim's site, some guy on twitter noticed it
Beta 10
Hi, Tim.
So moOde 4.0 BETA 10 has showed up on moodeaudio.org. Just downloaded it and have started a build.
I love this continuous integration activity!
Regards,
Kent
Hi, Tim.
So moOde 4.0 BETA 10 has showed up on moodeaudio.org. Just downloaded it and have started a build.
I love this continuous integration activity!
Regards,
Kent
Hi,
moOde 4.0 BETA 10 is available 🙂 This Beta contains two new features listed below. The Local UI feature requires installing Component 8 from Build Recipe 2.0.
- Local UI display
- Discover/Connect to other moOde Players
There is also an in-place update for Beta 6/7/8/9 -> Beta 10.
It MUST be run from cmd line AND on an un-squashed /var/www !! The browser title will revert to "moOde Player" after the update. Use System config to change it, then APPLY MPD settings to get the new DoP param.
sudo /var/www/command/updater.sh r40b10
Also, BE SURE to backup /var/www and /var/local/www directories before applying the update in case you need to revert!
-Tim
moOde 4.0 BETA 10 is available 🙂 This Beta contains two new features listed below. The Local UI feature requires installing Component 8 from Build Recipe 2.0.
- Local UI display
- Discover/Connect to other moOde Players
There is also an in-place update for Beta 6/7/8/9 -> Beta 10.
It MUST be run from cmd line AND on an un-squashed /var/www !! The browser title will revert to "moOde Player" after the update. Use System config to change it, then APPLY MPD settings to get the new DoP param.
sudo /var/www/command/updater.sh r40b10
Also, BE SURE to backup /var/www and /var/local/www directories before applying the update in case you need to revert!
-Tim
Attachments
I've upgraded a ZeroW and a Pi2 but the Pi2 is taking an eternity to do anything....
The zero was going slow so I told it to do a MPD update and seems better...
Both have a USB stick hanging off them...
More importantly, not showing my album art anymore ie there is a jpg in the same folder as the album.....
Having said that one album with a jpg extension in the folder suddenly started working!
But the other one with a jpeg file extension isn't - 'Cover art not found' 😕
The zero was going slow so I told it to do a MPD update and seems better...
Both have a USB stick hanging off them...
More importantly, not showing my album art anymore ie there is a jpg in the same folder as the album.....
Having said that one album with a jpg extension in the folder suddenly started working!
But the other one with a jpeg file extension isn't - 'Cover art not found' 😕
Last edited:
Hope I don't get burned to a crisp for asking, but as a totally incompetent Linux user is there ever likely to be another Moode image for Linux numpties like me? 😉
If not can anyone tell me if there are any other players out there with a specific driver for the 1794a chip?
If not can anyone tell me if there are any other players out there with a specific driver for the 1794a chip?