Open Sound System

I am having an issue using OSS in Ubuntu 20.04 along with Kernel 5.4.0-48-lowlatency that I hope someone can share insight to as I can not figure this one out. I am not sure if the issue is with OSS, Kernel 5.4, or jack1.

I am using the OSS deb file along with the patch as indicated in viewtopic.php?f=3&t=5882 as I need the Lynxtwo driver. Once the patch is applied, the driver compiles without error. The driver can also be started and stopped using sounon/soundoff without error. So it seems like the actual OSS driver is OK.

I am also using jack1 for recording/playback and it here where I see the issue.
It seems to be based on the sample rate selected.

If I start jack using the following:
jackd -v -doss -r48000 -p4096 -n4 -b -P /dev/dsp_out -C /dev/dsp_in
everything is OK and I can start and stop jack multiple times without error.

But if I change the sample rate to something faster such as 88200, 96000, 192000 then while jack seems to start without issue the input is not working. Output is working without issue. I also can not stop jack at this point without killing it.

Here are 3 outputs from jack in verbose mode showing what is happening.

This is what I see from the verbose output of jack with the sample rate at 48KHz. Everything is OK with no issues. Jack can be started and stopped multiple time without issue.

jackd -v -doss -r48000 -p4096 -n4 -b -P /dev/dsp_out -C /dev/dsp_in
jackd 0.125.0rc1
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd 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

getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_alsa.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_firewire.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_oss.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_dummy.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_alsa_midi.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_net.so
JACK compiled with System V SHM support.
server `default' registered
registered builtin port type 32 bit float mono audio
registered builtin port type 8 bit raw midi
clock source = system clock via clock_gettime
loading driver ..
start poll on 3 fd's
new client: oss, uuid = 8589934593 type 1 @ 0x5597d4a5e330 fd = -1
new buffer size 4096
resizing port buffer segment for type 0, one buffer = 16384 bytes
resizing port buffer segment for type 1, one buffer = 2048 bytes
registered port system:capture_1, offset = 16384
registered port system:capture_2, offset = 32768
registered port system:playback_1, offset = 0
registered port system:playback_2, offset = 0
++ jack_sort_graph
++ jack_rechain_graph():
-- jack_rechain_graph()
-- jack_sort_graph
oss_driver: /dev/dsp_in : 0x10/2/48000 (16384)
oss_driver: /dev/dsp_out : 0x10/2/48000 (16384)
oss_driver: indevbuf 16384 B, outdevbuf 16384 B
oss_driver: using barrier mode, (dual thread)
2365 waiting for signals
load = 0.0082 max usecs: 14.000, spare = 85319.000
load = 0.0123 max usecs: 14.000, spare = 85319.000
load = 0.0085 max usecs: 4.000, spare = 85329.000
load = 0.0066 max usecs: 4.000, spare = 85329.000
load = 0.0056 max usecs: 4.000, spare = 85329.000
load = 0.0052 max usecs: 4.000, spare = 85329.000
load = 0.0090 max usecs: 11.000, spare = 85322.000
load = 0.0110 max usecs: 11.000, spare = 85322.000
^Cjack main caught signal 2
starting server engine shutdown
stopping driver
server thread back from poll
unloading driver
freeing shared port segments
stopping server thread
last xrun delay: 0.000 usecs
max delay reported by backend: 81.000 usecs
freeing engine shared memory
max usecs: 14.000, engine deleted
cleaning up shared memory
cleaning up files
unregistering server `default'
no message buffer overruns

This is what I see when the sample rate is set to 88.2KHz:

jackd -v -doss -r88200 -p4096 -n4 -b -P /dev/dsp_out -C /dev/dsp_in
jackd 0.125.0rc1
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd 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

getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_alsa.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_firewire.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_oss.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_dummy.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_alsa_midi.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_net.so
JACK compiled with System V SHM support.
server `default' registered
registered builtin port type 32 bit float mono audio
registered builtin port type 8 bit raw midi
clock source = system clock via clock_gettime
loading driver ..
new client: oss, uuid = 8589934593 type 1 @ 0x555d2f645330 fd = -1
start poll on 3 fd's
new buffer size 4096
resizing port buffer segment for type 0, one buffer = 16384 bytes
resizing port buffer segment for type 1, one buffer = 2048 bytes
registered port system:capture_1, offset = 16384
registered port system:capture_2, offset = 32768
registered port system:playback_1, offset = 0
registered port system:playback_2, offset = 0
++ jack_sort_graph
++ jack_rechain_graph():
-- jack_rechain_graph()
-- jack_sort_graph
oss_driver: /dev/dsp_in : 0x10/2/88200 (16384)
oss_driver: /dev/dsp_out : 0x10/2/88200 (16384)
oss_driver: indevbuf 16384 B, outdevbuf 16384 B
oss_driver: using barrier mode, (dual thread)
2374 waiting for signals

As can be seen it seems to be waiting for signals from the driver. At this point I am not able to stop jack without killing it.
If I try to start jack again using 48KHz, I can see where /dev/dsp_in is generating an error:

jackd -v -doss -r48000 -p4096 -n4 -b -P /dev/dsp_out -C /dev/dsp_in
jackd 0.125.0rc1
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd 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

getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_alsa.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_firewire.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_oss.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_dummy.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_alsa_midi.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_net.so
JACK compiled with System V SHM support.
server `default' registered
registered builtin port type 32 bit float mono audio
registered builtin port type 8 bit raw midi
clock source = system clock via clock_gettime
loading driver ..
start poll on 3 fd's
new client: oss, uuid = 8589934593 type 1 @ 0x55757b4be330 fd = -1
new buffer size 4096
resizing port buffer segment for type 0, one buffer = 16384 bytes
resizing port buffer segment for type 1, one buffer = 2048 bytes
registered port system:capture_1, offset = 16384
registered port system:capture_2, offset = 32768
registered port system:playback_1, offset = 0
registered port system:playback_2, offset = 0
++ jack_sort_graph
++ jack_rechain_graph():
-- jack_rechain_graph()
-- jack_sort_graph
[OSS: failed to open input device /dev/dsp_in: oss_driver.c@464, errno=16 <-------- Error
OSS: failed to set fragment size: oss_driver.c@314, errno=9 <-------- Error
oss_driver: /dev/dsp_out : 0x10/2/48000 (16384)
oss_driver: indevbuf 16384 B, outdevbuf 16384 B
oss_driver: using barrier mode, (dual thread)
2414 waiting for signals
load = 0.0035 max usecs: 6.000, spare = 85327.000
load = 0.0053 max usecs: 6.000, spare = 85327.000
load = 0.0062 max usecs: 6.000, spare = 85327.000

The output is working fine so it seems the input device file is hung up.
Once this happens I also can't stop the OSS driver using soundoff.
The only way to get back to working on capture is a reboot.

It is not possible to use modprobe to unload the drivers:
modprobe: FATAL: Module oss_usb is in use.
modprobe: FATAL: Module lynxtwo is in use.
modprobe: FATAL: Module osscore is in use.

If anyone has any ideas on what the issue might be that would be great as I am not sure what to try at this point.

Thanks, Dan

Upon further research looking for the issue, I also tried to use ossrecord which directly uses the OSS driver without jack.
When used at 48KHz ossrecord works as expected.
Can be used multiple times no issue as noted below

ossrecord -v -s48000 -d/dev/dsp_in test.wav
Recording wav: Speed 48000Hz 16 bits Stereo
test.wav [.... ] 4.00 secs^C

But when used at something above 48KHz, it segfaults:

ossrecord -v -s96000 -d/dev/dsp_in test.wav
Recording wav: Speed 96000Hz 16 bits Stereo
Segmentation fault

So it seems that perhaps there may be an issue with the driver, the patch that was applied, or the kernel.

danjp wrote:Upon further research looking for the issue, I also tried to use ossrecord which directly uses the OSS driver without jack.
When used at 48KHz ossrecord works as expected.
Can be used multiple times no issue as noted below

ossrecord -v -s48000 -d/dev/dsp_in test.wav
Recording wav: Speed 48000Hz 16 bits Stereo
test.wav [.... ] 4.00 secs^C

But when used at something above 48KHz, it segfaults:

ossrecord -v -s96000 -d/dev/dsp_in test.wav
Recording wav: Speed 96000Hz 16 bits Stereo
Segmentation fault

So it seems that perhaps there may be an issue with the driver, the patch that was applied, or the kernel.

danjp wrote:I am using the OSS deb file along with the patch as indicated in viewtopic.php?f=3&t=5882 as I need the Lynxtwo driver.

Perhaps the Lynxtwo driver is not "open source", and, therefore, your "recompiled" version of it may not support HiRes such as 96000Hz.

Devices supported only by retail version of OSS:
Lynx AES16 Studio Interface
Lynx AES16-SRC Studio Interface
Lynx AES16e Studio Interface
Lynx AES16e-SRC Studio Interface
Lynx-L22 Studio Interface
LynxONE Studio Interface
LynxTWO-A Studio Interface
LynxTWO-B Studio Interface
LynxTWO-C Studio Interface
_http://manuals.opensound.com/devlists/Linux.html

The Lynx2 OSS driver does support sample rates up to 192KHz in OSS as I had it working without issue on Ubuntu 18.04 with kernel 4.15.

I have also used the OSS binary driver with patches in prior releases without issue so I don't think there is an issue with using a patch against the binary.

I upgraded to 20.04 and this is when the issues started.
So it is probably something specific to kernel 5.4 even though it compiles without error after the patch is applied.

Perhaps there are other patches that need to be applied that I am missing?

For clarity I am applying the patch against the precompiled binary after it fails the install.
I then issue a "sudo sh install.sh" command from the /usr/lib/oss/build directory after applying the patch as noted in the other post.

danjp wrote:Perhaps there are other patches that need to be applied that I am missing?

For clarity I am applying the patch against the precompiled binary after it fails the install.
I then issue a "sudo sh install.sh" command from the /usr/lib/oss/build directory after applying the patch as noted in the other post.

If I understood you correctly, you somehow managed to hack the retail version of OSS4 ("closed source").
But it does not work as expected, because, perhaps, some patches are missing.

The source code of OSS4 (which may not contain the the Lynxtwo driver), is said to be here:
_https://sourceforge.net/p/opensound/git/ci/master/tree/

It might be possible to clone the current version of source code, as well as an older version.
See:
_https://githowto.com/getting_old_versions
_https://stackoverflow.com/a/12256157
_https://stackoverflow.com/a/60406991
_https://sourceforge.net/p/opensound/git/commit_browser

Then, you may calculate "diff"
_https://en.wikipedia.org/wiki/Diff
_https://en.wikipedia.org/wiki/Patch_%28Unix%29

Attached is the output from dmseg.

I first cleared the buffer, then ran ossrecord at 96KHz that seg faulted, and then ran dmseg to get the info from the crash.
Not sure but it looks like the issue is with the lynxtwo driver. Probably needs to be recompiled for the later kernels.

Since this particular driver is not open source, it looks like I will have to wait until an updated binary is made available for the newer kernels.

Until that happens, I have installed kernel 4.20 and everything is working fine with that kernel.

From dmesg.txt, RIP: 0010:_ZN15CHalSampleClock3SetEih+0x1cb/0x1bf0 [lynxtwo] shows the content of the instruction pointer when the fault occurred. This points to the next instruction to be obeyed and as it is not at the entry point of function _ZN15CHalSampleClock3SetEih I would assume that the fault lies within this function. Without access to the source code for the lynxtwo module it is not possible to provide a fix or diagnose further.

This may be a long shot but I notice that the lynxtwo driver does have a configuration option, lynxtwo_init_order which determines if the output devices files are created before the input ones (0) or vice versa (1). As the problem occurs on record but not playback it may be worth setting this option to 1 and checking if it is still record (and not playback) that causes the fault condition.

As root:
echo lynxtwo_init_order=1 >>/usr/lib/oss/conf/lynxtwo.conf && soundoff && sync && soundon