What would happen when the system is powered, but there arduino doesn't start for some reason, so the is no control? Will the Buffalo stampede? Is that why it is called Buffalo?

Just kidding. I'm worried that the volume could be up all the way, destroying ears and speakers.

EDIT: And what if arduino stops working when it is already up and running? Will all registry settings be kept until is it switched off?

Edited by user Saturday, April 28, 2012 4:13:33 PM(UTC)  | Reason: Not specified

I do at the moment, but want to use the B3 for it if it is better sounding. Good to know that the registers don't get changed when arduino it turned off. Two more questions:

1. How reliable is arduino. Is it likely to crash or does it run very stable?
2. I was thinking of some sort of check before powering the dac board. Something like a function that loops for some time (with sleep/delay), let say 2 seconds (or less), and then switches a relay so the dac board gets powered. After this time it is sure that the arduino has started without problems. Will it then be fast enough to mute the dac?

Edited by user Saturday, April 28, 2012 4:34:11 PM(UTC)  | Reason: Not specified

Arduino is a solid state device just like the DAC, so equal reliability.

Some people don't like relays in signal wires. You could put a relay between amp and speaker and if Arduino fails to start, then the relay is not activated. Lock and mute are h/w signals out of the DAC. It would be useful to have them connected to the front panel.

There is a register that tells you whether there is a signal lock or not, but you need to read that register at the same instant that there is a loss of lock. The way the code works now, it reads the register once every two seconds and almost always if there is an unlock event, it misses reading it.

Edited by user Sunday, April 29, 2012 10:23:50 PM(UTC)  | Reason: Not specified

I see, should read more carefully :-)

Regarding the unlocks: they only last a fraction of a second. Reading the register only takes a fraction of a second, so you must read the register exactly when the unlock is happening. You could have the code constantly read the status register but then it would be "too busy" to attend to other tasks. (like volume, remote, display). I thought 2-second interval for reading the status register was a good tradeoff between status accuracy and usefulness.

IVI have a relay to prevent thump buster at start up. You can modify the circuit and control this relay by Arduino.

Regards

I'd be more worried about about Buffalo resetting to default register values for some reason during playback than Arduino crashing. Initializing the i2c takes some time tho, so you might hear a loud noise for a split second during boot. It's important that first things you do is to init the i2c and mute the dac and go from there. Only after that start displaying cool boot OSD animations and stuff ;). I used my own firmware software, not the Hifiduino one on my particular implementation.

The 0dB "feature" has happened to me a few times during turning on the DAC. It also happened once or twice during playback...maybe an ESD from spdif...dunno...totally random events. These few events happened during couple years time period. Yes, it produced a very, very loud sound and i glad my speakers could take it for those few seconds of total panic and paralyzing terror :).

What i ended up doing is checking once every second or so that the Buffalo volume level matches (regs 0 and 1) the volume level i currently had in a variable (+- channel balance) in the Arduino firmware and then reset the registers they didn't match (i also muted the dac and displayed an OSD message just to see how frequently it reboots/resets). The es9018 ramps up the volume relatively slowly, so instead of getting totally dramatized by the loud volume, you'll barely just get little scared and it is all over before you even react to it and the volume never reaches 0dB. I did not notice any downside of this sound-wise. I tried enabling/disabling it for a while. However using the i2c constantly didn't work too well (every loop() cycle or even once every ~50ms was too much).

However, there must be a better way to do this. For instance by motoring some pin in the Buffalo board using interrupt routine in the Arduino to see if the voltage level raises or goes low. There were thoughts of monitoring if the (empty) firmware socket's power goes down and back up again (if it even does in that case?). But never cba'd to research this further, since the "volume polling" solution worked good enough and the problem occurred very rarely.

Edit: My buffalo (32s of BII) was on 24/7. Might have something to do with that also. However if it never happens with Volumite, it could be some implementation specific issue.

Edited by user Thursday, May 10, 2012 1:02:31 AM(UTC)  | Reason: Additions

at first I will be using a pre-amp. This is desired in case I mess something up. When the system is stable and well funtioning then the pre will be removed. I don`t know about the constant i2c communication with the dac. I guess this degrades the actual performance of the dac, although elviz writes he can`t hear any differences.

I have been going though the code and tweaked quite a lot. I added more functions for the remote and made it possible to change the gui to show only the selected input or to show all input settings. The code you wrote is perfect for adapting it to your own needs. Thanks for that. Hopefully my dac will be sent real soon, so i can build it and start testing..

I`m not going to adjust the gain of my amplifier, if you are suggesting this. I`m not that scared actually that the dac will reset itself for some reason. When this happens it is likely to be caused a power failure . In this case arduino will also restart so there`s no problem.

For what other reasons could or should the dac reset itself?

You could use the lock status or retrieve the DPLL value.

That should work. If it doesn't, you could revert to register 27.