New build with balanced outs - almost there


#1
4 new photos · Album by Luke Tidd

So I naively went with the DAC+ Pro XLR from hifiberry.
I think it will be great, and yes I haven’t built a case yet

I think I could only really test the “back” and “select” knobs but they seem to be working fine.

When I select a program, it freezes, and never does anything else. Perhaps some config needs to be changed to use the different DAC? Any ideas of things to test?


#2

Hi @habys!

First, you must update the software from the admin menu. Also the library. Do it twice, please :wink:

http://wiki.zynthian.org/index.php/Zynthian_Box_Updating

After that, you should be able to access the webconf tool from your browser:

http://wiki.zynthian.org/index.php/Accessing_Zynthian_from_your_computer

From there, you can configure your soundcard and other things …

Good luck!


#3

So, thanks for that, I’ve updated everything.
Problem is when I have the cable plugged into the GPIO pins extended through the DAC, nothing shows up with aplay -l.
If I turn it off, unplug the cable, power it on and run aplay -l I get:

# aplay -l card 0: sndrpihifiberry [snd_rpi_hifiberry_dacplus], device 0: HiFiBerry DAC+ Pro HiFi pcm512x-hifi-0 [] Subdevices: 0/1 Subdevice #0: subdevice #0

Maybe on this different DAC there is a different GPIO pin requirement or something…? Maybe there’s not enough amps to power the screen and DAC?
Not sure. My power supply gives 2.4 amp. That seems like a lot, but I don’t have a lot of experience.

Any suggestions are appreciated.


#4

edit: I’ve tested some more. I can see the DAC and play audio with everything connected except the 2in1 Module.
I would like to test with the standard hifiberry but I don’t have another pin header at the moment.


#5

Perhap it’s a I2C problem. Hifiberry and 2in1 both uses I2C interface. Bad i2C connection in 2in1 would affect to Hifiberry. Have you doble checked the 2in1 wiring? Are you connecting correctly the I2C wires?

This could help you:

http://wiringpi.com/examples/quick2wire-and-wiringpi/testing-the-i2c-modules/

Using the “gpio i2cd” you should see something like that:

root@zynthian:/zynthian/zynthian-ui# gpio i2cd
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                       

The “20” is the MCP23008 in the “2in1” and the “UU” is the Hifiberry :wink:

Regards!


#6

I’m solved.

I connected the ic backwards… I’ve fixed it now. :slight_smile:


#7

Ah, I didn’t. I think I’ve damaged the board removing and resoldering the MCP23008-E/P. The DAC is usable but MIDI doesn’t work. If you press a lotta keys, one or two really weird notes come out but that’s it.


#8

Hi, @habys!
Are you using RPi3?
I have RPi3 …and I’ve spent a lot of time trying to make MIDI input work, but unsuccessfully.
Seems, there are still some issues with UART’s firmware and baudrates, so MIDI messages get corrupted.
In my ‘best-working’ setup, I get only the first MIDI message intact, and all of the following messages have corrupt first byte.


#9

Hi,
I’m using RPi3 and didn’t have any issues with the baud rate so far. The only issue, that the midi to serial converter driver doesn’t support “Midi running status”, but it is independent of RPi type. This can cause the mentioned things. Try to switch off your keyboard/sequencer “running status” support if you can.
http://midi.teragonaudio.com/tech/midispec/run.htm


#10

Hi @Schpion,

I am using RPi3 for my Zynthians without any problem. Really strange… what kind of opto coupler do you use? Some time ago I use something else than the 6N138 and that one (I don’t know the type) was too slow for MIDI processing…

Regards, Holger


#11

Hi @C0d3man,
I use H11L1. I have tested it with oscilloscope at every possible pin, all the signals are correct.
But when I look at MIDI message dump, I see corrupted bytes.
Surprisingly, the FluidSynth deals easily with such corrupted messages (I think it just ignores the first byte :smiley:), but the other synths don’t.


#12

It’s really strange. Are you using an official gorgona image? Could you send your boot/config.txt?


#13

Yes, I’m using Gorgona. Firstly, I’ve updated it twice (multilayer&webconf). The MIDI input didn’t work at all. After that I ran rpi-update several times.

Currently, I’m using this (‘best-working’) configuration:

# Disable Splash Screen
disable_splash=1

# Disables dynamic frequency clocking
force_turbo=1

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=spi=on

# Disable Blutooth Support for HifiBerry compatibility with RBPi 3
# Swap back the ttyAMA0 to GPIO
dtoverlay=pi3-disable-bt 
dtoverlay=pi3-miniuart-bt

# Adjust Serial Port Clock to allow MIDI baudrate 31250
dtoverlay=midi-uart0

# Soundcard Config
dtoverlay=hifiberry-dac

# Display Config
display_rotate=2
hdmi_drive=1
hdmi_group=2
hdmi_mode=1
hdmi_mode=87
hdmi_cvt 800 480 60 6 0 0 0
dtoverlay=ads7846,cs=1,penirq=25,penirq_pull=2,speed=50000,keep_vref_on=0
dtparam=swapxy=0,pmax=255,xohms=250
dtparam=xmin=3950,xmax=150,ymin=3950,ymax=250

This works with FluidSynth only. All the other synths give hung notes.


#14

Have you removed these lines from the file?

# Adjust Serial Port Clock to allow MIDI baudrate 31250
[pi2]
init_uart_clock=2441000
init_uart_baud=38400
dtparam=uart0_clkrate=3000000
[pi3]
init_uart_clock=39062500
init_uart_baud=38400
dtparam=uart0_clkrate=48000000
[all]

These lines are needed in order to get the MIDI-IN port working correctly.
What is really strange is that FluidSynth works. It shouldn’t without these lines …

Regards!


#15

For some reason, these lines didn’t set the uart’s clock properly. I got totally corrupted bytes from serial port.
I tried different combinations of clocks, but all with no success.
After that, I’ve updated the system. I’ve noticed that some new overlays appeared after update.

So, I have removed the lines mentioned and placed the following line instead of them:

dtoverlay=midi-uart0

This line works better on my system (but not the best).