IR-controlled B3SEpro
Hi there,
Since January, I've been deploying I2C control of my B3SEpro DACs via Hermes-BBB in 128fs mode (so called PureSync or TrueSync), setting the DAC registers by shell scripts or python scripts by francolargo (Thanks, Frank!); no need for on-board firmware (whether original or beta).
For more interactive control, one solution recommended by Frank was using NetIO, which appeared very attractive, but I looked for more old-fashioned methods such as using an infrared remote control which can send IR codes to execute shell scripts or commands on the I2C-connected computer with the DAC.
An LIRC (Linux IRC) package can be used for this purpose but unfortunately there is no appropriate lirc serial module like lirc_rpi on the current debian BBB system.
So, I gave a second life to my old RasPi B+ as a device to control both of I2C and IRC. After confirming the IR receiver connected to the RasPi works well, I set up an LCD to verify and display the results of executed commands.
This LCD was also connected to the RasPi via I2C by an I2C expander (PCF8574) and also converted to a member of device files as /dev/lcd0, so that the input of simple words or sentences can be directly displayed on the LCD screen, making far easy to write executing scripts.
After that, I prepared various combinations of small scripts grouped into five categories: Input selection; OSF setting, Automute setting, DPLL setting and FIR setting. These five groups were assigned to the individual buttons on the IRC so that they can be executed by irexec (a binary from LIRC) running on the RasPi. Each group has more than one command scripts but the config file of irexec can make it possible for them to be toggled each other within one particular button, quite convenient in a limited setting
The picture below is the prototype of this system. The result was quite good and now I'm enjoying semi-interactive IR control of the DAC as shown in a sample movie here. The DAC is set to 128fs for DSD sources and please notice that it can be set to SPDIF mode on the fly.
BTW, the I2C-connected DAC in this movie is a B3SE9028pro, receiving audio signal (DSD512 from HQ player) via an isolated USB to I2S/DSD PCB (XMOS 768kHz with 45/49 MCK from DIYINHK). The SQ is quite good.
Regards,
Hi there,
Since January, I've been deploying I2C control of my B3SEpro DACs via Hermes-BBB in 128fs mode (so called PureSync or TrueSync), setting the DAC registers by shell scripts or python scripts by francolargo (Thanks, Frank!); no need for on-board firmware (whether original or beta).
For more interactive control, one solution recommended by Frank was using NetIO, which appeared very attractive, but I looked for more old-fashioned methods such as using an infrared remote control which can send IR codes to execute shell scripts or commands on the I2C-connected computer with the DAC.
An LIRC (Linux IRC) package can be used for this purpose but unfortunately there is no appropriate lirc serial module like lirc_rpi on the current debian BBB system.
So, I gave a second life to my old RasPi B+ as a device to control both of I2C and IRC. After confirming the IR receiver connected to the RasPi works well, I set up an LCD to verify and display the results of executed commands.
This LCD was also connected to the RasPi via I2C by an I2C expander (PCF8574) and also converted to a member of device files as /dev/lcd0, so that the input of simple words or sentences can be directly displayed on the LCD screen, making far easy to write executing scripts.
After that, I prepared various combinations of small scripts grouped into five categories: Input selection; OSF setting, Automute setting, DPLL setting and FIR setting. These five groups were assigned to the individual buttons on the IRC so that they can be executed by irexec (a binary from LIRC) running on the RasPi. Each group has more than one command scripts but the config file of irexec can make it possible for them to be toggled each other within one particular button, quite convenient in a limited setting
The picture below is the prototype of this system. The result was quite good and now I'm enjoying semi-interactive IR control of the DAC as shown in a sample movie here. The DAC is set to 128fs for DSD sources and please notice that it can be set to SPDIF mode on the fly.
BTW, the I2C-connected DAC in this movie is a B3SE9028pro, receiving audio signal (DSD512 from HQ player) via an isolated USB to I2S/DSD PCB (XMOS 768kHz with 45/49 MCK from DIYINHK). The SQ is quite good.
Regards,
Attachments
Last edited:
I love your cases twluke!
They look like they are designed by Russian KGB agents during cold war era
Properly quirky and cool!
I love your cases twluke!
They look like they are designed by Russian KGB agents during cold war era
Properly quirky and cool!
Uh, thank you for your kind words.
No objections to the lack of elegance in the current DAC case, which was previously used as a box of external power supply containing Placid HDs.BTW, the lower one, previously used as a B3SE 9018 DAC with multiple SPDIF inputs, is now working as a dual-mono B3SE9028pro DAC with a Hermes BBB for I2C and I2S connections.
Regards,
Nice work, Twluke! As I have mentioned in our conversations, I think sharing some of our DIY solutions for DAC control help to fill an important need. I have recently been experimenting with a couple SBC's other than the RPi because of its network bandwidth limits. The aspect where the RPi really shines is in the reliability and predictability of the kernels and OS. I'm now making four USB->Buffalo-3 DACs for others in my family, and we'll be using RPi3B+ SBCs for control. [We ruled out an LCD display because we can get that information on our phones.]
FYI, the Odroid-N2 has a built-in IR receiver but I have not tested it. For now I'm only using the Odroid for a media server and in that role it is a clear improvement over the RPi3B+ (and another 'premium' SBC that I tested). In the future the Odroid-N2 will also become the master control interface for the high-resolution part of the home AV system. I might try adding IR control commands in python. Whether the code is python or simple shell scripts, one can use 'Netcat' to send control commands to any *other* SBC on the network (as long as it is listening on an open network socket...). Maybe a useful backup if WiFi drops-out...
Cheers,
Frank
FYI, the Odroid-N2 has a built-in IR receiver but I have not tested it. For now I'm only using the Odroid for a media server and in that role it is a clear improvement over the RPi3B+ (and another 'premium' SBC that I tested). In the future the Odroid-N2 will also become the master control interface for the high-resolution part of the home AV system. I might try adding IR control commands in python. Whether the code is python or simple shell scripts, one can use 'Netcat' to send control commands to any *other* SBC on the network (as long as it is listening on an open network socket...). Maybe a useful backup if WiFi drops-out...
Cheers,
Frank
Ian found Buffalo IIIsePro's firmware bug and he has published a simple solution.
https://www.diyaudio.com/forums/dig...mate-weapon-fight-jitter-499.html#post5807923
https://www.diyaudio.com/forums/dig...mate-weapon-fight-jitter-499.html#post5807923
Man I was expecting great news like... price drop (OK maybe I'm asking too much
At least the bug is found, hope it gets its way up to Russ!
Russ doesn't like other people's discussion forum appear here. This message should be deleted soon. However, I hope Russ can fix this bug very quickly.
The issue is already fixed. There was a bug - but it is actually pretty edge case - it also was also the type that was fixed by a simple documentation change. two settings were transposed - but they were not default cases - and almost all users would never have encountered it.
The updated README shows the correct switch setting for format selection:
Notice all that changed were RJ (very uncommonly used) and the second (non-default) way to select I2S
GitHub - twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware
Cheers!
Russ
There was a bug - but it is actually pretty edge case - it also was also the type that was fixed by a simple documentation change. two settings were transposed - but they were not default cases - and almost all users would never have encountered it.The updated README shows the correct switch setting for format selection:
Notice all that changed were RJ (very uncommonly used) and the second (non-default) way to select I2S
GitHub - twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware
Cheers!
Russ
Yeah - I have no problem with posts of that nature as long as they are constructive and not attempting to peddle some other product.
Ian has given me no cause to object to his posts - and I think the intent here was to raise awareness of something easily fixed. Mission accomplished.
This is exactly why the firmware is open-source.
Ian has given me no cause to object to his posts - and I think the intent here was to raise awareness of something easily fixed. Mission accomplished.
This is exactly why the firmware is open-source.
Last edited:
Hello, i finally managed to flash Truesync 128fs firmware in an Attiny85 for my 9038 Buffalo dac. Result is quite good, BIII sounds more natural and "easy", with better spatial separation between instruments. I use hqplayer to convert to DSD256, ethernet to my BBB NAA and then I2S to the dac.
But there is a problem: loud pops everytime a song ends (1 or 2 seconds after the music stops), that put at risk my speakers...
Obviously i have automute enabled, but that doesn't seem to work (it worked ok with default firmware). Any idea?
But there is a problem: loud pops everytime a song ends (1 or 2 seconds after the music stops), that put at risk my speakers...
Obviously i have automute enabled, but that doesn't seem to work (it worked ok with default firmware). Any idea?
I use hqplayer to convert to DSD256, ethernet to my BBB NAA and then I2S to the dac.
But there is a problem: loud pops everytime a song ends (1 or 2 seconds after the music stops), that put at risk my speakers...
Obviously i have automute enabled, but that doesn't seem to work (it worked ok with default firmware). Any idea?
I have no direct experience with the HQPlayer NAA, but have had similar experiences in synch mode with PCM player programs: annoying pops when signal frequencies change. I was unable to completely eliminate them using any of the 9038 automute parameters. However, I found that lowering the BBB player buffer size significantly decreased the intensity of the noise. If it is possible to decrease the buffer size used by HQP NAA, perhaps that could also improve the noise. ...just speculation, but worth a shot...
-snip-
But there is a problem: loud pops everytime a song ends (1 or 2 seconds after the music stops), that put at risk my speakers...
Obviously i have automute enabled, but that doesn't seem to work (it worked ok with default firmware). Any idea?
According to the ES9038pro datasheet, automute only works for PCM and SPDIF modes; not for DSD.
As I'm controlling the B3SEpro via I2C for this truesync (actually 128fs mode) setting, I can not figure out the actual cause of your problem. But with the similar setting (Roon/HQP and botic BBB as NAA for DSD512 play), I have experienced no intertrack pop noise when listening to one particular album or even through random play of any playlists.
Even after newly starting HQP to play via Roon, there has been no particular pop noise when the music starts to begin.
So, I can only list some possible ideas to solve your problem:
If using 45/49 clocks on the Cronus, setting DSD512 on HQP may avoid pops in truesync mode. If using 22/24 clocks, setting DSD128 may show better resutls.
The second idea is to change the jumper position of the clock divider on the Cronus (ignoring appropriate mathematical ratio) with fixed DSD256 on HQP, because 128fs mode is somehow mysterious
.The third one is to modify the clock setting in the /boot/uEnv.txt on the BBB (22/24 to 45/49 with the 1:1 jumper ratio on the Cronus, if using 45/49 clocks).
These are only my assumption. Sorry if not work.
That's strange, as using standard firmware with the same system and parameters absolutely no pop/noise at songs stop were produced with automute enabled...
I confirm no pop noise when a songs ceases by itself and another song starts. The noise only occurs when i press "stop" or i start another song while one is already playing
If using 45/49 clocks on the Cronus, setting DSD512 on HQP may avoid pops in truesync mode. If using 22/24 clocks, setting DSD128 may show better resutls.
The second idea is to change the jumper position of the clock divider on the Cronus (ignoring appropriate mathematical ratio) with fixed DSD256 on HQP, because 128fs mode is somehow mysterious
The third one is to modify the clock setting in the /boot/uEnv.txt on the BBB (22/24 to 45/49 with the 1:1 jumper ratio on the Cronus, if using 45/49 clocks).
I use 45/49 clocks on Cronus and DSD256 in hqp (my PC cannot play DSD512 for performance reasons).
So i should set 1:1 clock divider on Cronus? What should i write in /boot/uEnv.txt?