On Sun, Jan 18, 2009 at 04:53:41PM -0500, Nick Guenther wrote:

> straight `jackd` was very stuttery (because of xruns), but after some
> experimenting I have settled on:
> /usr/local/bin/jackd -R -d sun -r 44100 -p 4096 -n 4
> (44100 because audacity and hydrogen use that as a default sample
> rate, 4096 because 2048 was still stuttery sometimes)
> 
> Here is my audio card:
> azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x02: irq 7
> azalia0: codec[s]: Realtek/0x0888
> audio0 at azalia0

-R is useless.  OpenBSD doesn't have realtime support.

upgrade to -current.  lots of fixes in azalia.  your stuttering problem
is most likely because your device doesn't record properly at 44100 Hz.
this has been fixed long ago in -current.  alternatively, you can use
-i 0 to disable recording if you you still want to use 44100 Hz.

and when you upgrade to -current, you can use the sndio backend,
which uses 44100 Hz by default because that's what libsndio uses
by default.

> 
> It works pretty well, but it's still not ideal, though. In playing a
> song with vlc+vlc-jack I noticed that it would click and pop
> sometimes. I looked at the song in Audacity and indeed it does get
> very near to +1.0 in the part where I hear the pops. However I killed
> jackd and ran vlc again on the same song and the pops were gone. So
> jackd must be overscaling, or perhaps BSD's oss underscales by
> default. I've been googling but no one seems to have this specific
> problem. Does anyone have any pointers?

again, update to -current.  this was a rounding problem in jack.

(and jackd doesn't use OSS on OpenBSD)

> Another (more minor) problem is that I can't start jackd from. I can't
> run it from /etc/rc.local because it needs to be tied to a specific
> user (unless you use jackstart, appearently, but that didn't come in
> the package presumably because it's a linuxism). And anyway if I run
> jackd and the progams that use it in the wrong order or kill jackd and
> restart it underneath them or even sometimes (but not always). I've
> stuck it in a script for now, but does anyone have any clever ideas to
> make running jackd more convenient?

you are supposed to run jackd as the user who will be using it.
it's not really intended as a general purpose sound server, but as
you noticed, if you "jack" up the latency, it actually works fairly
well for that purpose.

anyway, aucat is a much better sound server.  again, you'll have
to update to -current to get that.

> Another problem is that switching windows sometimes makes the audio
> cut out for a moment. I was seeing this before I installed jackd too,
> but perhaps I can tweak jackd to avoid it?

probably not easily, but you can jack up the latency more and see what
happens.

> http://www.nabble.com/noise-during-playback-td9766320.html suggests
> you can either tweak your IRQs or run jackd with --realtime, but that
> you also need to increasing the mlock limit if you're not running
> jackd as root. I've found out how to increase the limit on Ubuntu but
> I can't figure it out for OpenBSD :(.

-R/--realtime is useless on OpenBSD.

> -Nick
> 
> p.s. By the way, what is libsndio? Is it an audio mixer in base,
> finally? I found a bunch of scattered posts about it and even the
> sio_open(3) man page in cvsweb but nothing that explains specifically
> what the goal is.

libsndio is a new audio API.  among it's benefits is the ability
to use different "backends" transparently, currently either audio(4)
or aucat(1) in server mode.

aucat can be used as a sound server in -current.  unfortunately the
manuals on the web don't get updated all to often, but you can
snag a -current version of the manual from cvs or whatever.

in my experience, it works much better than any other sound server
for both general purpose and more "advanced" usages.  the one
feature of other sound servers that I miss is far out weighed by
aucat's impeccable reliability compared to those other servers, which
is ultimately the most important criteria for me.

-- 
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

Reply via email to