Ubuntu Server 18.04 on Raspberry Pi 3B+

[phofman]

I did realize that running and tuning a multichannel chain (based on a non-DIY RME Fireface ) would hardly achieve the quality of a well tuned dual channel DIY-DAC setup.

Why?

 

[soundcheck]

That's simple. Because of the DAC implementation and limitations in the first place.

Basically all great DSPing (crossover, equalization, roomcorrection. etc) and
optimizations on a PC (or e.g. also MiniDSP) won't have much value,
if your (untouchable) DAC turns out to be the bottleneck at the
very end of the digital chain.

If you'd follow what people over here do to push the DACs out there to the limits,
you'd see the point. (Projects based on e.g. Allo Katana or Soekris based DACs IMO can prove that point.)

I did try.

I e.g. replaced the power supply on my FireFace - which made a nice difference - it still wasn't good enough to me on the long run.

Thinking that so called ProAudio equipment would be the cream of the cake - at least by some folks out there - I consider a misconception.
Which of course doesn't mean that ALL $40 HATs in whatever basic config are doing better. It's rather the other way around.

I did enjoy the FireFace, it just wasn't good enough.

 

[phofman]

I see, you talked about your fireface specifically. Because in general I do not see a reason why a multichannel setup should perform worse than dual channel.

 

[CharlieLaub]

I really don't see the point in your efforts now, Soundcheck.

Take your example of a 44.1kHz digital file or stream that is upsampled to 384k or what ever high rate you choose. You claim that doing this gets around the DACs anti aliasing filter, and you are correct. But the 44.1k file already has anti-aliasing applied to it, right in the file/stream itself. This will not in any way be eliminated or reversed by upsampling.

My personal feeling is that the DACs anti aliasing filter is just another FIR filter applied to the signal, and you can read the datasheet to learn about its properties. What exactly is so bad about it? I mean what is the scientific and objective, not "my ear says" subjective, reason for doing what you are doing?

At this time my opinion is that high rate DSD and PCM is a fad like many things in audio. It has its proponents, but the underlying evidence in favor of it is a bit sketchy to me. It's something exciting and new to sell to the consumer, for sure.

 

[CharlieLaub]

Default alsa device is the pulse plugin which offers no controls of type MIXER.

I finally figured out how to fix this issue, and to get HDMI audio working for Ubuntu Server 18.04.2.

First I installed pluse audio

sudo apt update
sudo apt install pulseaudio

Then I had to edit the "config.txt" file. Under Ubuntu Server for Raspberry Pi 2/3 this file is located in the folder /boot/firmware. I added:

dtparam=audio=on
hdmi_drive=2

These turn on audio and force hdmi audio even if connected to a non-audio DVI monintor.

Now when I type aplay -l I see:

**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 7/7
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: ADAT [USBStreamer ADAT], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Before these steps only card 1 was listed and card 0 was omitted from the list completely. Now alsamixer runs without having to specify which card to load up.

I was able to test the HDMI audio using speaker test:

speaker-test -Dhw:CARD=ALSA,DEV=1 -c2 -t wav

speaker-test 1.1.3

Playback device is hw:CARD=ALSA,DEV=1
Stream parameters are 48000Hz, S16_LE, 2 channels
WAV file(s)
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 256 to 32768
Period size range from 256 to 32768
Using max buffer size 32768
Periods = 4
was set period_size = 8192
was set buffer_size = 32768
 0 - Front Left
 1 - Front Right
Time per period = 2.404090
 0 - Front Left
 1 - Front Right

 

[phofman]

What is the role of pulseaudio in that pure-alsa setup? IMO you would get the same results with that device tree config alone.

 

[CharlieLaub]

What is the role of pulseaudio in that pure-alsa setup? IMO you would get the same results with that device tree config alone.

Probably nothing. You had mentioned in an earlier post that pulse was the default audio device, and that was why card 0 was "missing", so I installed it. Only later did I add the lines to the config.txt file.

Anyway, I doubt pulse audio is getting in the way since there is no desktop or apps that will not be using ALSA directly.

 

[phofman]

Well, I meant it as a case where a device with no MIXER controls gives this warning in alsamixer. If you list such device in amixer contents, it will give all the other non-mixer (typically PCM) controls.

I would not want to have PA present in this system since a running PA usually blocks a device. Also alsa configs in ubuntu workstations (I do not know about the server variant) are modified from stock alsa configs to always prioritize the pulse plugin as a default.

The way to avoid PA blocking the device is to disable the device in PA configuration (e.g. via pavucontrol). But if you do not need PA in your setup and if the distribution allows for easy removal, no reason to fuss with it.