New system/internal sound - Jack is borked

Hi there,

I know there are some jackd wizards here, so perhaps somebody has an idea what’s going wrong. I have a new setup with Debian 11, and a rather weird Realtek internal sound card that shows up as follows in aplay -l:

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 10: HDMI 4 [HDMI 4]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 11: HDMI 5 [HDMI 5]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 12: HDMI 6 [HDMI 6]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: sofhdadsp [sof-hda-dsp], device 0: HDA Analog (*) []
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: sofhdadsp [sof-hda-dsp], device 1: HDA Digital (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: sofhdadsp [sof-hda-dsp], device 3: HDMI1 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: sofhdadsp [sof-hda-dsp], device 4: HDMI2 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: sofhdadsp [sof-hda-dsp], device 5: HDMI3 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Playback through Pulse and aplay work without problems. E.g.

$ aplay -c 1 --dump-hw-params 'test.wav' 
Playing WAVE 'test.wav' : Float 32 bit Little Endian, Rate 44100 Hz, Stereo
HW Params of device "default":
--------------------
ACCESS:  RW_INTERLEAVED
FORMAT:  U8 S16_LE S16_BE S24_LE S24_BE S32_LE S32_BE FLOAT_LE FLOAT_BE MU_LAW A_LAW S24_3LE S24_3BE
SUBFORMAT:  STD
SAMPLE_BITS: [8 32]
FRAME_BITS: [8 1024]
CHANNELS: [1 32]
RATE: [1 384000]
PERIOD_TIME: (2 4294967295)
PERIOD_SIZE: [1 1398102)
PERIOD_BYTES: [128 1398102)
PERIODS: [3 1024]
BUFFER_TIME: (7 4294967295]
BUFFER_SIZE: [3 4194304]
BUFFER_BYTES: [384 4194304]
TICK_TIME: ALL
--------------------

But jack doesn’t like it. First of all, I might have forgotten one step, because if I start jackd from terminal, qjackctl doesn’t notice. On my old system, qjackctl would immediately recognise the default jack server starting, and reflect that in the UI.

Now, let’s say I start from qjackctl:

13:40:10.798 JACK is starting...
13:40:10.798 /usr/bin/jackd -dalsa -dhw:sofhdadsp -r44100 -p192 -n2 -P -o2
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Cannot create RT messagebuffer thread: Operation not permitted (1)
Retrying messagebuffer thread without RT scheduling
Messagebuffer not realtime; consider enabling RT scheduling for user
no message buffer overruns
13:40:10.819 JACK was started with PID=46829.
Cannot create RT messagebuffer thread: Operation not permitted (1)
Retrying messagebuffer thread without RT scheduling
Messagebuffer not realtime; consider enabling RT scheduling for user
no message buffer overruns
Cannot create RT messagebuffer thread: Operation not permitted (1)
Retrying messagebuffer thread without RT scheduling
Messagebuffer not realtime; consider enabling RT scheduling for user
no message buffer overruns
jackdmp 1.9.17
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2021 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio1
creating alsa driver ... hw:sofhdadsp|-|192|2|44100|0|2|nomon|swmeter|-|32bit
configuring for 44100Hz, period = 192 frames (4.4 ms), buffer = 2 periods
ALSA: final selected sample format for playback: 24bit little-endian
ALSA: use 2 periods for playback
Cannot use real-time scheduling (RR/10) (1: Operation not permitted)
AcquireSelfRealTime error
13:40:12.898 JACK connection change.
13:40:12.899 Server configuration saved to "/home/hhrutz/.jackdrc".
13:40:12.899 Statistics reset.
13:40:12.902 Client activated.
13:40:12.902 Patchbay activated.
13:40:12.903 JACK active patchbay scan...
13:40:12.903 ALSA active patchbay scan...
13:40:12.904 JACK connection graph change.
13:40:13.105 JACK active patchbay scan...

First of all, I didn’t manage yet to start in duplex, only either playback only or capture only seem to work. Then there are these funny RT messages. When I sudo-apt-installed qjackctl, it did ask me to set up real-time, and I double checked all elements, they seem to correspond with this document, e.g. there is /etc/security/limits.d/audio.conf, I added my user to the audio group etc.

Next funny thing is the allowed block sizes. I cannot use the usual 512 or 1024, it seems to require 96, 192, etc.

And then, worst of all, audio playback is completely distorted, as if the database of the stream wasn’t even correct.

Any clues?

Huh, at least I got playback working now, I think I found a thread that is describing exactly the starting problem and noise bug; Bug #1872244 “Jack audio not working on Ubuntu 20.04 running on ...” : Bugs : jackd-defaults package : Ubuntu

  • use 1008 block size for jack
  • use force-16 bit
  • use block-size 16 for SuperCollider (so that 1008/16 is integer)

d’oh, what an annoying configuration.

I immediately thought about that thread! Some built-in soundcards have those weird hardcoded buffer sizes. What were they thinking!?

As I understood, it’s not really the fault of the sound card, but the open source firmware project basing the buffer sizes on “1 millisecond at 48 kHz” or something like that: https://github.com/thesofproject/sof/issues/2572 ; I’ll observe that issue, it’s unclear whether it should actually have been fixed.

So it turns out now, you can set buffer size to (48 lcm 64) = 192 and multiplies thereof. Now I run with 768 buffer size and regular 64 block size for SC, seems ok.

For the record, if anyone has this weird sound card (Realtek ALC295). To get both mic and laptop speaker working, you have to find the right sub-device. This eventually worked for me:

/usr/bin/jackd -dalsa -r48000 -p768 -n2 -S -D -Chw:1,6 -Phw:1,0
1 Like

I actually bought a Lenovo this summer and ended up returning it because of this issue. Nice to see you got it working with supercollider.