Trying to build a portable media rig that can use whatever hardware happens to be handy. The mic volume was fixed here, with this (after figuring out the dependencies and how to replace the automatically-installed version), and I think the only thing left now is to use an HDMI TV as an external display and speakers.
ALSA and PulseAudio work just fine: play some music with VLC, send it to HDMI, and it works.
JACK doesn’t, even after the fix that I linked to above.
JACK won’t even start if I set its interface to either of the HDMI options:
That’s fine, as my overall architecture assumes that it’s connected to the internal card anyway. (PCH) But I tried it just for the data point.
When I try to add the HDMI output as an additional device, I get this (video):
The sine oscillator is coming from the laptop speakers, and is supposed to be split verbatim to the TV. But the TV makes intermittent noise instead. Each burst of noise is synchronized to an “excessive timing error”, as shown below, ad infinitum:
It does that even by itself, without the other devices that I had in the video just to figure out which one it was. All of the others did nothing at all, and that one had the noise, so I’m pretty sure that’s the TV.
Possibly the HDMI interface requires particular parameter settings, which you will have to enter manually into your zita-a2j configuration.
There is a script which Paul or Robin created to display which devices are in use and what settings are used.
You could connect an application through the HDMI interface using ALSA or PulseAudio, and run the script to see what settings are used.
This command will download and run the script all from one long command line:
cd /tmp && wget https://community.ardour.org/files/adevices.sh && bash ./adevices.sh
Perhaps the HDMI device requires using 16 bit word length or some other setting which is not default.
I agree some other setting. I notice no -p being sent to zita-j2a. I expect -p 1024 (or higher) may be needed. The default is 256. Try 1024, 2048 and 4096 till one works. Pulse (and pipewire these days) seems to default to 4096 though they sometimes buffer a lower setting on the way… sort of like using jack set to 1024/4 for example.
I think the actual data stream is just AES3/spdif so either 16 or 24 bit (or anything in between) should work fine and be auto detected by zita-ajbridge.
That is strange, standard sample rate for (commercially produced) videos has been 48kHz for decades, it seems strange that a video interface would only support 44.1kHz sample rate.
More likely that either you have a Pulse configuration file setting 44.1k as the default rate, or you were playing a file which was 44.1k sample rate and so the playback software requested that rate when the interface was opened.
The alsa-utils package has a script named alsa-info.sh which will print out all the information about audio interfaces found in the system.
It is very verbose and a little difficult to read through, but it will have a section describing available rates like this (from a Radeon video card):
Codec: ATI R6xx HDMI
AFG Function Id: 0x1 (unsol 0)
Vendor Id: 0x1002aa01
Subsystem Id: 0x00aa0100
Revision Id: 0x100700
No Modem Function Group found
Default PCM: rates [0x70]: 32000 44100 48000 bits [0x2]: 16
formats [0x1]: PCM
I did not find anything about required buffer sizes listed. I suspect that the change in buffer sizes may be all you needed, and if you wanted to continue using 48kHz for some reason it may be possible at the higher buffer sizes.
That could have been. My library has a mixture of 44.1k and 48k, and I had it on shuffle. Don’t remember which one it was anymore.
If PA’s default is 44.1k, then I’d raise an eyebrow to Ubuntu Studio being designed for serious content creation. But I suppose it’s still a possibility.
aaron@aaron-ubuntustudio-m6800:~$ sudo apt install alsa-utils
[sudo] password for aaron:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
alsa-utils is already the newest version (1.2.6-1ubuntu1).
0 upgraded, 0 newly installed, 0 to remove and 36 not upgraded.
alsa-info.sh: command not found
Where is it?
Possibly. But I also got to thinking though, that most of what this rig will play is consumer stuff, and a lot of that is 44.1k. And the recording that it produces will also go directly to its consumers. It’s a portable, live, “good enough” rig that works anywhere with anything, not an audiophile studio.
PulseAudio isn’t really relevant for content creation, it was made to simplify normal desktop use. It is kind of a toss-up which is more appropriate for desktop use, DVD audio is 48k, but CD and a lot of video files are 44.1k audio, so 44.1k default is a reasonable choice.
On Fedora it gets installed to /usr/sbin/alsa-info.sh.
Then probably just something to keep in mind for future reference.
I guess that makes sense. You’re more likely to use JACK instead. But that makes the transition to PipeWire more interesting, if it’s supposed to replace both simultaneously so that the other two no longer exist.
I keep wondering too, when digital media will be good enough by default to not worry about such things. Essentially a “perfect black box that handles media”, and nobody has to look inside. And then I remember that data storage still costs something, and networks aren’t infinitely fast, and you don’t always need lossless 4k120 video with 64-bit 192kHz audio…
bash: /usr/sbin/alsa-info.sh: No such file or directory
A recursive search of the root directory (/) found it here:
ALSA Information Script v 0.4.60
This script visits the following commands/files to collect diagnostic
information about your ALSA installation and sound related hardware.
See '/usr/share/alsa-base/alsa-info.sh --help' for command line options.
Newer version detected: 0.5.2
To view the ChangeLog, please visit http://www.alsa-project.org/alsa-info.sh.changelog
ALSA-Info script has been downloaded /tmp/alsa-info.Lsjen6T4tl.
Please, re-run it from new location.
aaron@aaron-ubuntustudio-m6800:~$ /usr/share/alsa-base/alsa-info.sh --help
alsa-info.sh version 0.4.60
--with-aplay (includes the output of aplay -l)
--with-amixer (includes the output of amixer)
--with-alsactl (includes the output of alsactl)
--with-configs (includes the output of ~/.asoundrc and
/etc/asound.conf if they exist)
--with-devices (shows the device nodes in /dev/snd/)
--with-dmesg (shows the ALSA/HDA kernel messages)
--output FILE (specify the file to output for no-upload mode)
--update (check server for script updates)
--upload (upload contents to remote server)
--no-upload (do not upload contents to remote server)
--pastebin (use http://pastebin.ca) as remote server
--stdout (print alsa information to standard output
instead of a file)
--about (show some information about the script)
--debug (will run the script as normal, but will not
aaron@aaron-ubuntustudio-m6800:~$ /usr/share/alsa-base/alsa-info.sh --no-upload --output ./alsa-info.txt
dmesg: read kernel buffer failed: Operation not permitted
Your ALSA information is in ./alsa-info.txt
I ran it both with and without the TV hooked up and while a diff viewer found a lot, I couldn’t tell that any of it was significant. Searching it for [rates] turned up either [rates [0x0]:] or [rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000]. The list varies some, but it always includes [44100 48000].
Just an FYI:
Ubuntustudio has to use the packages provided in the ubuntu repo. As such pulse comes as it is being 44100 from upstream. I would argue rather, pulse is just a way of getting audio from the desktop, nothing to do with proaudio which would use either ASLA directly or Jackd.
I did end up changing back to 48k, and I did end up with that buffersize. So the command to connect my HDMI TV to JACK is now: zita-j2a -j SPK0 -d hw:CARD=NVidia,DEV=3 -c 2 -r 48000 -p 4096
And it works.