IanCanada's Latest RPi GB Goodies Impressions... and your tweaks, mods and hints...

Controlling ESS registers directly from the driver would breach the ESS copyright. But sending I2C commands to the added MCU like all the other manufacturers do is OK. That allo driver would be really quite simple to modify and probably the result would make it to the RPi kernel. The allo driver was created in the very same way using another pre-existing driver (as quoted in allo driver credentials), it's all GPL.
 
Just to clarify phofmans potenially slightly misleading statement.

I just copied the header of the Katana codec of the most current RPI kernel.

* Driver for the ALLO KATANA CODEC
*
* Author: Jaikumar <jaikumar@nnnn.nnn>
* Copyright 2018
*

That's Allo paid work.
They wrote the Katana codec/driver themselves. They had to.
It's proprietary work.
It requires reverse engineering and a compliant ON-DAC MCU firmware. That firmware is not opensource!
Ian therefore would need to write his own firmware matching the codec.
Since he knows both sides of the MCU it'd be possible.


Allo do uses an available codec for their now "entry" level Piano and Boss DACs. Because these DACs do not have the Sabre Copyright issues. That's what I refered to earlier when e.g. talking about HifiBerry stuff being reused.
However on the driver side Allo quickly advanced over the basic HifiBerry
driver. The introduction of e.g. master mode for HAT DACs, pretty much eliminating the need for a reclocker, and getting HATs into serious audio territory is one of Allos contributions if I'm not mistaken.

Enjoy.
 
linux/allo-katana-codec.c at rpi-4.19.y * raspberrypi/linux * GitHub is a GPL code for a regular ASOC-standard driver which "only" sends I2C commands to the MCU. Anyone can copy/use/modify provided the GPL license is kept. The driver is not different from other RPI drivers in that directory since they all are very similar - I2S base linux/bcm2835-i2s.c at rpi-4.19.y * raspberrypi/linux * GitHub + I2C control commands in the corresponding .c module file.

The MCU already exists in the controller, the alsa driver is basically ready, only incoming I2C control in the MCU would have to be coded (which may or may not be a lot of work, depending on how the firmware is written).

But I understand the option to control the DAC independently and provide just I2S lines can be useful + it makes the product different from the competing items.
 
If "We" includes me I've to disappoint you. Since years I do maintain a quite close contact to this or that manufacturer (Ian is not one of them).
From time to time I'm even involved in the design/pre-launch processes.


And I do know about Ian's position, since we had the driver discussion some months back. Somebody made a driver available.
I didn't have the impression that Ian wasn't interested at first. Unfortunately the driver in question was a driver that would have
caused a serious ESS Sabre copyright violation. That driver would have never made it into the official RPI kernel. That's a fact.
I do think at the point in time Ian's driver ambition dropped great time. And that's now my opinion.
Because I've havn't seen any driver discussions ever since. ;)


However. Times might change. I hope so.
As I said earlier. Perhaps Ian is able to do some reverse engineering on the Katana driver and update his
MCU firmware accordingly. It's the same DAC. It's pretty much the same functionality. And the driver is accessible.
If that's possible. That could save him a hell lot of work.

Until then I keep lurking around here once in a while and enjoy my Allo stuff. ;)

Enjoy.

Thanks God "Ian is not one of them." then, because "we" would be all RPI copuled. Instead we have choices and Ian can reach out for the people like to make the driver avaliable if he wants to.
 
if you do your homework properly.

Quite strong words. Have you ever programmed an MCU?

The Audiophonics driver could also be a rolemodel for Ian.

I do not see any major difference between linux/allo-katana-codec.c at rpi-4.19.y * raspberrypi/linux * GitHub and I-Sabre-K2M/i-sabre-codec.c at master * SatoruKawase/I-Sabre-K2M * GitHub It is all copy/paste from some earlier I2C-based ASOC driver. No problem with it, that's why we have GPL.

The Audiophonics board is a different animal, using DSP CPLD for automated rate/format detection etc. Ian's controller is plain STM32F103 for control. I like the chip he uses, there are some nice tools to program. One day I will learn more the wonderful ChibiOS for STM32 ChibiOS free embedded RTOS - ChibiOS Homepage . It makes the small dirt-cheap chip a real computer with preemptive multithreading, inter-thread communication constructs, easy debugging etc. A board for 3 dollars programmed via USB from arduino IDE becomes a powerful device, incomparable to Arduino Nano for the same price. But that is another story...
 
Last edited:
Folks. Keep in mind.

I brought it up on the other thread covering Ians DAC.

Ian's HAT DACs, as good as they look, don't come with Linux SW drivers! For all of you considering his DAC, keep in mind there are no control options via web-browser or application.

From that perspective Allo is lightyears ahead. And Ian will have a hard time to catch up. I actually doubt he's considering it.

If you're into computer based audio or streaming you simply can't neglect the SW part of your audio devices anymore.
Estimated 99% of all RPI HAT DAC manufacturers have realized that and did something about it. Several manufacturers
just built a DAC that was compatible with other companies drivers to cover that area.

Using the Katana or the Audiophonics iSabre9038Q2M driver would be difficult for Ian, since the MCU firmware is proprietary.
Ian would have to build into his controller MCU the Katana/Audiophonics firmware. I don't think he'll get access to these.
He might be able to do some reverse engineering. After all. This simply is not gonna work.

Ian has to write the driver himself, of course he can use the existing stuff as base. Perhaps he gets some help.


Enjoy.

Thanks for the redirection.
 
I'm still waiting for my stuff to arrive, but I have a question about hardware volume control:

The manual says:
Connect to the RaspberryPi as usual. In the player’s configuration dialog, select generic I2S DAC (for hardware based volume control from ESS controller), or PCM5122-compatible DAC (such as Hifiberry DAC+) if you desire additional hardware volume control from player UI. Restart the player if required.

So it sounds like the volume control can be controlled in hardware. Ideally I'd like to be able to control the DAC hardware volume both witht he ESS controller and also with the software interface in moode or volumio. Is that possible?

With my Naim Uniti Atom, there is a bidirectional control when using Airplay. Either the computer running iTunes or the remote app can raise and lower the hardware volume control on the Naim, and when I walk over to the unit and turn the volume knob the volume changes in itunes as well. I would like to match that functionality in this setup if possible. Does it work that way?


Thanks,
Sheldon
 
I just got my parts today. I have been playing with it a bit. I have the fifopi and dual mono DAC above it and the ESS controller also attached.

I have Moode 4.4 on my Pi and the DAC selected is a hifiberry DC+. I try a track and the fifo I2S light lights up and the LEDs for the two clocks (D8 and D9) flash back and forth and the empty light stays lit. The lock light does not light, and the ESS controller says no input.

At the moment, I'm powering the Pi through the micro usb. I'm powering the FIFO with 5V from an HP lab supply, and the DAC hat with another output on the same supply. I've got 5V to the Fifo and 3.3V to the dac hat.


I'm going to try volumio tomorrow and see if I have better luck, but with some initial searching, I don't see anything that describes a behavior like that.

Sheldon
 
I have Moode 4.4 on my Pi and the DAC selected is a hifiberry DC+. I try a track and the fifo I2S light lights up and the LEDs for the two clocks (D8 and D9) flash back and forth and the empty light stays lit. The lock light does not light, and the ESS controller says no input.

Suggest you try plugging the DAC into the rpi w/o the fifo to see if that works - to determine if the fifo is the problem. Plug the ESS controller into the DAC directly.

Check also the two clocks on the fifo are of the correct freq. Note also there are two power inputs on the fifo - the one marked 3.3V/5V is the one for the fifo logic.

That's all I can think of now. I have tried DietPi and piCorePlayer using hifiberry DAC+ and both work.
 
Last edited:
With my Naim Uniti Atom, there is a bidirectional control when using Airplay. Either the computer running iTunes or the remote app can raise and lower the hardware volume control on the Naim, and when I walk over to the unit and turn the volume knob the volume changes in itunes as well. I would like to match that functionality in this setup if possible. Does it work that way?

I'm going to answer my own question for those who might also be curious.

I'm using Moode 4.4 with Ians hardware. So this may be specific to moode, but it seems like it's universal to shairplay, mpd, and alsa:

With airplay to the Pi, I can indeed change the hardware volume control with the iTunes volume slider. But it's one way. iTunes has no idea that the volume was changed by another means, whether that means is by the moode web interface, or the ESS controller volume knob. Also song information and artwork is not transmitted to the Pi (or not requested or not handled). The web interface just has a big black screen that says "airplay".

I was hoping to build something that would rival my Naim uniti, and from a user interface and software standpoint this isn't quite there. My goal was to build an enclosure with the 7" raspberry touch screen and a nice volume knob, but with iTunes fighting with the local volume knob, I'm not sure what I'll do at the moment.


Sheldon
 
iTunes has no idea that the volume was changed by another means, whether that means is by the moode web interface,

1) I do not think there is any known way of passing the changed volume of an airplay device back to the iTunes controller Unofficial AirPlay Protocol Specification

2) Alsa-based projects monitor changes in values of alsa controls by checking for changes with alsa-lib API call snd_mixer_handle_events event handling - ALSA volume change callback not triggering? - Stack Overflow . E.g. calling that API in amixer and alsamixer which can monitor the changes Search * snd_mixer_handle_events * GitHub . MPD monitors the changes too Rate limit * GitHub

IIUC: iTunes AirPlay support is handled by shareport-sync. That API function is not called by shareport-sync Rate limit * GitHub .

IMO what you ask for is not technically possible for AirPlay/iTunes.

or the ESS controller volume knob.

If there is no driver specifying the alsa volume control element handling volume control via the ESS controller, how could the driver -> alsa-lib -> alsa player be notified of a volume change performed by the controller?
 
If there is no driver specifying the alsa volume control element handling volume control via the ESS controller, how could the driver -> alsa-lib -> alsa player be notified of a volume change performed by the controller?

I haven't gotten my ESS controller yet, but reading the manual it does state that if you use a PCM5122 driver you can enable Web UI volume control via S2. I wonder if Ian's controller is emulating a PCM5122 chip so that volume can be changed via ALSA.
 
I haven't gotten my ESS controller yet, but reading the manual it does state that if you use a PCM5122 driver you can enable Web UI volume control via S2. I wonder if Ian's controller is emulating a PCM5122 chip so that volume can be changed via ALSA.

That's what I've been saying. It requires a bit of reverse engineering.

I didin't know he's been using the PCM5122 driver.

If Ian knows what GPIOs, protocol and commands/registers are being used
he can simply respond to that on his MCU.

BTW. The Audiophonics iSabre ES9038Q2M driver made it now officially
into the kernel. It's probably easier to handle than the Allo driver.
 
A few years back there was a good Battery power (quality of power produced) study .
Genuine research, using lab grade equipment in controlled conditions.. not some guy in his basement..
All the currently available battery types were tested.
Surprising result was that the oldest technology Nicad batteries provided the cleanest/most stable power.
So clean that it was below the measurement threshold of the test equipment.
NO other battery types/chemistries even came close to the venerable Nicads performances... 'nuff said.
Trick now would be to actually find some (they are still 'out there ' tho )