[WORKAROUND] OSS4 Audigy4 garbled sound

JohnLM · n00b Joined: 20 Apr 2009 Posts: 71 Location: LATVIA

NOTE: There is a workaround. Read last or last few posts

After setting up OSS4 with certain measure of blood, sweat and headache it works -- well sort of.

The Problem:
The thing is that when a sound application reconnects to (disconnects/closes and then connects/opens) /dev/dsp
sometimes sound is missing or sometimes worse - digital noise at max volume comes out.

For example mpd disconnects from /dev/dsp when it changes song (so I get pretty good chance of no music or shitting my pants with noise at incredible volume).

Peculiarly enough according to ossinfo -v the vmix disconnects from sound device as well, when there's no client apps. Even more it shows both vmix and my client app as using "sound engines". From which I deduct it uses HW mixing capability of sound card (which doesn't seem to be well supported).

Info:
I'm running a Creative SB Audigy4 (which uses oss_sblive driver)
My OSS is an slightly modified oss-4.2.2002.ebuild from Bugzilla
More info on my previous topic about setting up the thing.

Probable solutions:
Well from what I can understand I need to do whole mixing in software and then pass to sound device thru persistent connection.

If not, I guess I need a secondary sound server. Well I like JACK, but it doesn't play nice with oss on non-realtime kernel (dunno if on realtime one either), so unless you have good ideas it's a no go too.
Then there is Pulseaudio. I've had nothing but headache in the past (w/ Ubuntu), but as for general use sound server there is nothing much else (what ain't old or/and deprecated).

So, is anyone else having this bug?
Can I and how to configure vmix to remain constantly hooked up to the device?
Or should I use a secondary sound server?

EDIT: I just realised that the noise is in fact a tiny (perhaps a single sound frame?) piece of input sound stuck in looping. So when there is "sound missing" it is actually a "silent piece" looping itself over again, instead of really missing sound.
_________________
"I reject your reality and substitute my own" - A. Savage

soka · Posted: Mon Sep 27, 2010 12:28 pm Post subject:

I had a similar problem with an audigy 4 some time ago, check my post at 4front-tech.com and see if it can help you.
http://www.4front-tech.com/forum/viewtopic.php?f=3&t=3932

Naib · Posted: Mon Sep 27, 2010 10:21 pm Post subject:

isn't /dev/dsp the legacy oss interface and you should be jacking into the newer ossv4 /dev nodes?
_________________

JohnLM · n00b Joined: 20 Apr 2009 Posts: 71 Location: LATVIA

JohnLM · n00b Joined: 20 Apr 2009 Posts: 71 Location: LATVIA

Just installed the mercurial build of OSS 4.2 (b 2003/201010311349)
Testing it two days now, and it doesn't seem to get rid of the problem completely.
Sound is sometimes still missing, but it is playing more often than not, so it's a good change.
Hadn't had the beep/noise bug yet, but a there's a new one... some extra harmonics over an actual sound.

What do you guys think of Pulseaudio instead of vmix for mixing?
_________________
"I reject your reality and substitute my own" - A. Savage

Naib · Posted: Mon Nov 01, 2010 10:54 am Post subject:

Anon-E-moose · Posted: Mon Nov 01, 2010 11:17 am Post subject:

My personal philosophy is to use what works.

Oss4 (2003) works fine for my chipset (nvidia onboard) that doesn't mean it's for everyone.
If it's not working well for you, then retry alsa/PA. With each new release problems get fixed (most of the time :lol:

)
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

JohnLM · n00b Joined: 20 Apr 2009 Posts: 71 Location: LATVIA

JohnLM · n00b Joined: 20 Apr 2009 Posts: 71 Location: LATVIA

*BUMP*

Still not solved, and PulseAudio doesn't work either. Seems like both OSS and system-wide support is dropped/disabled/masked in PulseAudio making it unsuitable to me.
JACK did work, but there was sound stuttering... a LOT. (JACK doesn't seem to play nice in non-realtime kernel with OSS)

Hmm, maybe I should write a "silent daemon". It could constantly feed /dev/dsp with silence, hopefully keeping vmix always busy (so it never disconnects from "sound engine").
Doesn't seem nice to write an apparently no-op program to run in background but it will have tiny footprint and CPU usage.
_________________
"I reject your reality and substitute my own" - A. Savage

PaulBredbury · Watchman Joined: 14 Jul 2005 Posts: 7310

JohnLM · n00b Joined: 20 Apr 2009 Posts: 71 Location: LATVIA

JohnLM · n00b Joined: 20 Apr 2009 Posts: 71 Location: LATVIA

[ ... ]

Hmm... I have gotten no feedback on this thing whatsoever...
Am I the only one having this bug?

Anyways here is my little program, which is a "hack" to workaround this bug
The code can be found on http://johnlm.hopto.org/files/silenced.tar.gz

What it's for:
The OSS4 bug with Audigy mentioned in this thread manifests itself as silence or garbled sound.
This often would happen on song change in music player because most implementations shuts down and recreates new "sound session" on audio device.
This in turn causes a short time nothing uses the audio device and the /dev/dsp is "suspended". The resuming it is what causes this bug.
*Why* it is caused by it is a whole other question... for which the answer is not known to me.

The idea:
Write a small daemon that just outputs silence. This would keep the device busy. No other audio is affected cause vmix mixes them with the silent stream.
Since device is never "suspended", the bug is prevented to manifest itself. (It's not fixed, that's why this is a workaround)

Implementation:
A small C program which opens /dev/dsp, writes some zeros to activate the device then use OSS-specific SNDCTL_DSP_SILENCE ioctl() directive.
This keeps the device active, but requires no further writing of zero bytes. The program then daemonises itself (if requested) and by pause() call is halted until a signal (SIGINT or SIGTERM) arrives.

You could use