• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Control of BBB-based audio appliances

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Member
Joined 2007
Paid Member
Frank, this is just marvelous. I am understanding only 10% of how you did it, but got to learn this as a complete digital chain incl. crossover would be my dream as well. I have now first to bet my normal setup working and than will follow your example. THX for the effort to share.

...glad to share, @Blitz! I am now re-installing and tweaking the existing control scripts to work in Debian 8.3. There are a few issues to resolve. But the great thing about the newer Debian is that I can now run a set of crossover filters that are much more flexible to configure. In Debian 7.5 they did not function in ALSA. These filters should give superior results in most systems. My own needs are fairly simple because of a) the design of my DIY speakers, b) tweaks to my TPA Legato outputs, and c) the I2C 'preamp' controls on the remote control (this thread). But others can certainly benefit from the upgrade in crossover filters.

Once I'm back to controlling the system as I like, I'll replace my old calibrated microphone and get serious about final refinements. What I learn may influence how I decide to control the system remotely, so changes may be coming. In that effort I will also keep the crossover development thread updated as the evolution continues: http://www.diyaudio.com/forums/twisted-pear/277564-ladspa-filters-digital-crossovers-bbb.html
 
Member
Joined 2007
Paid Member
Low latency pass-through of USB audio to ALSA

I mentioned in the Botic driver support thread that I have been working on the last planned feature of my BBB-based system. That is, the ability to input audio from video sources and forward it to ALSA for filtering and low latency playback. It is working very well! I tried three different pieces of software and the lowest latency was achieved with SoX. It is so good that with most percussive sounds, the visuals seem coincident. Here is the current command line that I'm using:
Code:
chrt -f 45 sox --buffer 512  -c 2 -t alsa hw:1,0 -t alsa plug:TV-in &

SoX has many and varied features, but let me mention what I observed about latency and performance while using this application.

1. When starting up, the frequency of over/underruns is not constant. The program seems to adapt to the operating environment and will usually stabilize to create a usable stream. I don't know the reason for this adaptation, but it seems that the final latency one achieves after it stabilizes is about the same regardless of the stated buffer size - as long as that buffer is not extreme (either huge or so small that the program crashes).

2. I suspect, though can't test at present, that SoX adapts to embedded clocks of USB streams and does not resample. This remains to be confirmed. However, I find that up sampling my 48kHz output to 96kHz improves SQ somewhat. I do that up sampling in ALSA, in the plug-in i wrote named 'TV-in'.

3. The program benefits from running at a relatively high system priority. I set the priority just below that of the IRQ processes and it behaves much better than running at the default priority.

4. Running this way, Sox doesn't 'play nice' with normal system behaviors. Once a script launches SoX at high priority, that script will become unresponsive except to command-line intervention like control-C or 'pkill sox'. That is certainly no way to integrate a renderer into a multi-source 'pre-amp/DAC'! I even found that initiating SoX as an /etc/init.d service could not be reversed by stopping the service. Fortunately, I was able to modify the custom remote control server (netio_server.py) so that it would stop the process reliably.

Conclusion: My hopes for a way to enjoy good movie sound through the BBB have been realized. In a larger sense, USB input plus the many LADSPA digital filters allow the BBB to perform as a basic digital signal processor in addition to performing as a great asynchronous audio renderer. In a future post I will show my final configuration for the SPDIF->USB conversion. In order to use SoX to achieve low latency, it required a re-write of the remote control server and GPIO interrupt software, which I will discuss in the next post.
 
Member
Joined 2007
Paid Member
Updates to net_server.py and buttons.py

As mentioned above, low latency processing with SoX caused a mess of problems with my remote control and interrupt code. They are all fixed now, and the versions posted to GitHub are up-to-date.
https://github.com/francolargo/BBB-audio/tree/master

Brief list of changes:
1. The remote control server (netio_server.py) now runs without calling any subroutines. This is more stable, faster, and eliminates any possible danger from using shell=True.

2. A third TCP port was assigned to the server. This allows other programs to input commands that are executed by the server. In this case, GPIO inputs are generated by momentary switches on the chassis front panel. Instead of those input signals triggering individual scripts, now one script (buttons.py) simply injects some text into the TCP port of the remote control server. This causes it, in turn, to execute the commands as if they came from the iOS remote control. This capability represents a way to use the server interrupt/control program without buying the netio software! But honestly, the cost/benefit is minuscule to have the remote controls on an iPad and phone!

3. Interrupts from the front panel momentary buttons are handled by 'buttons.py'. It was re-written from the ground up. I found a couple of unknown functions built into the python GPIO module that were very useful. Information: Projects/AdaFruit GPIO - MinnowBoard Wiki
The function 'GPIO.add_event_callback(pin, callback)' makes it unnecessary to evaluate the source of gpio edges - the callback function is automatically triggered. Thus, the new 'buttons.py' is faster and more efficient. ...and again, no problem managing SoX running at high priority.

Conclusion: These re-writes bring the software a big step closer to 'done'. Certainly, these two python programs are now an adequate model for ways to control multiple functions of a BBB or RPi-based audio appliance.

Cheers! :)

Frank
 
Member
Joined 2007
Paid Member
Congrats ! That is again a step further than my setup...even though that my Stereo speaker are as well used for cinema, but sofar I switch the dac against the av-receiver when watching movies....

Thanks Blitz! With my system, I need the BBB because it is doing the crossover filtering. If you don't need that, then there are many more ways to get low-latency sound from video. But it has really surprised and pleased me to experience much more enjoyment of a good movie sound track! :D
 
Member
Joined 2007
Paid Member
miniStreamer as SPDIF->USB client

Here is a brief report on control of Toslink/USB inputs in my BBB-based system. Used for video sources, this is the last of my personal objectives for this system. I think it opens doors to expand the role of BBB/Hermes/Cronus into more general applications than those based on MPD or Squeezelite.

Hardware: I found an inexpensive ($35) and capable two-way converter to produce USB from either I2S or SPDIF. The 'miniStreamer' is based on the TE7022L USB streaming controller, and integrates well with Twisted Pear Toslink modules and an Otto-II. The max sample rate is 96kHz for both the Toslink->SPDIF converters and the miniStreamer. Together with an Otto-II they are working very well with Botic and the BBB/Hermes/Cronus setup to provide low latency crossover filtering for audio originating in my 'smart TV' or AppleTV.

Configuration: The miniStreamer board can apparently accept either consumer-level or TTL-level SPDIF signal. I configured my Toslink modules for TTL-level output. Power to the miniStreamer can come from the USB port or external supply, I chose external at 5.25 volts. This requires that the board's power jumper be left open. Also, the board should be used in 'master' configuration - another jumper setting. The firmware sets I2S as the default interface and this must be changed each time the miniStreamer is powered-up. [Thanks to @GDO for the tip!] Simply execute:
Code:
amixer -c miniStreamer cset numid=8 1

and again, for capture->playback streaming, I suggest:

chrt -f 45 sox --buffer 512  -c 2 -t alsa hw:1,0 -t alsa <your preferred alsa input> &

I do not run Squeezelite and SoX at the same time. When changing inputs I kill any output processes and restart depending on whether output goes to headphones (no crossover) or speakers (with crossover). For SoX, my preferred ALSA input is a plug in /etc/asound.conf that up samples to 96K, which helps slightly with source material that was resampled before it became SPDIF.
The Otto-II is off (OE=HIGH) unless one of the 'TV' inputs is selected - this is simple GPIO control through GPIO pin 8_9 for OE, and pin 8_7 for S. I'm still tinkering with the NetIO control code and will update the GitHub sources when I've ironed out a few little details.

Layout: I attached photos showing the miniStreamer in place. It sits partially above an aluminum plate covering the LiPO battery. I spliced the USB cable rather than hassle with buying a short one. To keep connections short, the Otto-II is positioned close to the GPIO header of the BBB and the Teleporters sandwich the output end of Cronus (direct soldered with silver wire). With the boards so tight, the airspace gets cluttered with wires! The decoupling caps on the power input to Cronus helped during testing (when Cronus I2S output connections were not ideal) so I left them. That power travels ~4 feet to reach the big multi-plug on the back panel.

Performance: My SPDIF inputs all come from streaming sources, so their resolution is limited. Still, anything mastered at 48/96 kHz can sound quite good! The AppleTV, of course, can transmit AirPlay streaming via USB to the BBB. Spotify on an iOS device can stream via AirPlay and on to USB, or the identical streams can arrive at the BBB via a plugin in Squeezelite. The AirPlay stream is resampled by the Apple hardware to 48k while Squeezelite plays Spotify at 44.1k. Quality-wise, Squeezelite easily wins, presumably because it avoids that final resampling. It's worth mentioning again that the USB input was intended primarily as a convenience - I'm not concerned about tweaking it from top-to-bottom for quality. This USB input to BBB/Hermes/Cronus is inexpensive and super-simple to implement in Botic so it seems silly to pick nits on SQ. That said, a good soundtrack in a 48k frequency multiple is still a real treat! :)

Cheers,

Frank
 

Attachments

  • IMG_2973.jpg
    IMG_2973.jpg
    750.1 KB · Views: 431
  • IMG_2975.jpg
    IMG_2975.jpg
    440.5 KB · Views: 440
  • Frontpanel.jpg
    Frontpanel.jpg
    70.5 KB · Views: 420
Last edited:
Member
Joined 2007
Paid Member
I updated the netio_server.py code on GitHub. It is running pretty well. One item that still needs work is a quirk where squeezelite will sometimes fail to launch. One advance comes from the observations of @Bunpie [ http://www.diyaudio.com/forums/digi...-reference-dac-8-channel-241.html#post4098779 ]. In my system, the 'no bandwidth' setting for DPLL clearly improves fidelity. The effect on sound quality is one I have heard before as a result of 'tweaking' driver cones: the speaker locations seem to disappear. Good stuff! [Unlike Bunpie's configuration, I'm running the B3s in asynchronous mode.]

BTW, taming speaker cone distortions should be the very final step in setting up a system. Best to minimize the need from the digital side first! :)
 
Last edited:
Member
Joined 2007
Paid Member
Continuing to learn about the es9018 register options, I'm plotting ways to control them and ALSA to easily enhance normal listening. I'm considering ways to address the various sonic differences in recordings and how to get the most enjoyment from each. Certainly, having a 'de-emphasis' button for older digital recordings seems worthwhile. Because I can control volumes of woofers, mids, and tweeters independently, I'm also planning to have a 'loudness' button to correct for perceptual differences when listening at low volumes. For movie soundtrack use, I can turn on a LADSPA compression filter in the ALSA crossover, and maybe also tweak frequency responses. All of this done remotely thanks to the BBB, the NetIO control program, and the custom python server that they run.

For overall fidelity, (in addition to running at 'no DPLL bandwidth') I'm getting improved performance by messing with the filters in register 14. In my system, lowering IIR bandwidth to 'normal' and switching to the slow rolloff FIR filter are each incrementally better than the default configuration, especially for midrange. For the tweeter DAC, the slow FIR rolloff gets noisy so the default fast rolloff filter is better.

If you have thoughts or ideas, I'd be happy to hear them!
 
Member
Joined 2007
Paid Member
Listening experiences while playing with es9018 registers 10 & 14:

With older recordings, activating the De-emphasis filter via register 10 is almost always rewarding.

The slow FIR rolloff expands the sound stage, which is usually welcome. With (what I would call) "high saturation" signals the FIR rolloff time definitely comes into play. My listening room remains too live, and a good oboe, blues harp, or operatic voice can really cause problems. Switching to the Fast FIR rolloff on the fly reduces the ringing.

I added buttons for these functions to the remote. On devices with smaller screens, I'll have to add a second page to hold these and any additional controls. The button labels change to indicate the status of the es9018 registers.

Cheers,

Frank
 

Attachments

  • IMG_0300.PNG
    IMG_0300.PNG
    209.9 KB · Views: 409
Member
Joined 2007
Paid Member
DO NOT change the es9028/38 filters on the fly via I2C! It was no problem with the es9018, but on the es9028 it *may have* caused a serious problem.

The price of experimentation:

I was sampling the various filters of the es9028's register 7 to choose my favorite. The early favorite was the apodizing filter, BTW, because it gave the most open sound stage. Anyway, I was changing music while the Brickwall filter was running and suddenly loud, odd noises came from both midrange channels. My worst fears were confirmed - melted voice coils. The setup is balanced, and this only happens if one side of a balanced signal is somehow grounded. The amp is fine, but both left and right side drivers smoked. I suspect something fishy happened briefly to the es9028 output. So, if your system is balanced be careful while experimenting! In the downtime I'd be happy to hear suggestions on 'best practices' for the future.
 
Member
Joined 2007
Paid Member
BTW, here are my quick listening impressions from one round (a very clean vocal track) as I cycled sequentially through all the filters:

name : hex code : first impression
fast rolloff linear 0x0 good clarity
slow rolloff linear 0x20 softer mids and transients
fast rolloff minimum 0x40 similar to previous
slow rolloff minimum 0x60 balanced - slightly brighter than 0x40
apodizing, etc... 0x80 open soundstage!
hybrid, etc... 0xc0 less detailed
brickwall 0xe0 higher definition than 0xc0
 
Last edited:
Member
Joined 2007
Paid Member
oh, that's unfortunate :(

does the datasheet mentions that the output must be temporarily muted during a filter change?

The data sheet doesn't mention anything about a need to mute. So, I've been thinking about every possible thing that could have gone wrong. The basic approach I'm using worked beautifully with the 9018s. I'm afraid it will be impossible to know for certain what happened yesterday. I really need to think carefully about how to proceed, so here are the possible causes I'm now considering:

1) Automute was default on the 9018, but on the 9028 the default automute config in register 2 is "normal operation". I chose '01' in bits [7:6], which simply drops volume to nothing. But the chip can also be set to ground all channels in order to run cooler (2'b10). While 2'b01 matches what was working fine with the 9018, in my system that automute setup didn't work quite the same on the 9028. It never happened before, but with the 9028 Squeezelite gave serious pops and thumps between tracks until I shortened the automute ramp time using register 4 - changing from '4' to '10'. But just before the the voice coils smoked, I heard a significant pop anyway. ...and the volume was fairly high... Could some of the DAC's internal channels have been grounded and others not? Or, was that particular thump such a surge that the delicate Lowther voice coils shorted in a moment? It didn't sound too bad - and there was some delay before the loud rising whine of the irreparable damage.

2) Remind me - I thought the BBB could use 'fast mode' I2C timing. I thought that with the 9018s, it was possible to use 'i2cdetect'. But with the 9028 I got:
Code:
root@beaglebone:/# i2cdetect -y 1
Error: Can't use SMBus Quick Write command on this bus
I just want to make sure that the commands issued from the BBB don't get ignored for any reason. If that's a possibility, then my code should do a register read to affirm each command. I'm not excited about that, but if its needed, then it must be done.

3) I don't particularly like that 9028 register 7 selects the filter shape parameters (which I was messing with) AND the least significant bit controls the mute function. I wonder if that mute is volume only, or is it the channel ground type?

4). Could there be something unique about the Brickwall filter, which was in place when the damage occurred? I rather doubt it, unless others have problems as well. But it would only affect those with fully balanced systems, and perhaps fragile high efficiency drivers. I'm driving Lowthers with a Sympatico amp. [I choose Lowthers because they have awesome motors. Their cones are a problem from the factory, but they can be modified to sound wonderful - I completed that cone treatment just a few weeks ago. :mad:]

So, lots of questions and not much data. I'll have a couple of weeks to digest this while new drivers come from England.

Moving forward, and all ideas from any perspective will be greatly appreciated!

Cheers,

Frank
 
Member
Joined 2007
Paid Member
Another anomaly - probably not relevant. On the 9028, individual channel (within the DAC) volume registers 16-23 are not doing anything. It doesn't matter what's written there, there's no effect. On the 9018, the analogous registers 0-7 were useable for balance.
 
Another anomaly - probably not relevant. On the 9028, individual channel (within the DAC) volume registers 16-23 are not doing anything. It doesn't matter what's written there, there's no effect. On the 9018, the analogous registers 0-7 were useable for balance.

Check register 15 bit 1 - that can disable individual channel volume but register 16 should work. Or you bypassed the OSF (register 37 bit 7) which I believe disables volume control which in turn could have caused the speakers problem.
 
Member
Joined 2007
Paid Member
Check register 15 bit 1 - that can disable individual channel volume but register 16 should work. Or you bypassed the OSF (register 37 bit 7) which I believe disables volume control which in turn could have caused the speakers problem.

For the foreseeable future I will abandon manipulations to registers 16-23. At the moment I’m auditing all of my settings that might have caused the signal to become ‘unbalanced’ and cause speaker damage. I notice that default for register 15 is 01. I don’t get it. Bit 3 is reserved and the data sheet says it should be 1, so wouldn’t default be 0x09? ...and if I want to set up in stereo mode (which sounded as if it was working), wouldn’t I use 0x0d?
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.