[haiku] Re: HDA audio driver - more testing, possible patch?

Thanks for your replies, Stephan, Ryan!

I've been doing some more tests, and I've since uncovered some
potentially significant findings -- they don't really invalidate the
previous test results, but they certainly shed new light.
I'll get to that in a moment!


Stephan Assmus <superstippi@xxxxxx> wrote:
> On Haiku, if the system is stressed enough, the buffer duration
> is actually still not long enough. Ingo is currently hard at work
> to write "whole system" analysis tools, and these problems will
> eventually be tackled.

Ah, okay. I haven't had the chance to test the driver under Haiku.
The last time I checked, Haiku didn't have drivers for Adaptec
SCSI cards, which posed a boot problem on this machine, and
unfortunately since the "soundcard" is onboard, I can't really move
it into a Haiku-supporting machine!
Do we still lack Adaptec drivers?

If you think it's absolutely critical to test it under Haiku,
I might be able to set up an alternative hard disk for this machine.
I usually try to avoid interfering with it too much since it's my
"production" machine, but if need be...


As for the latency, if Haiku needs a higher buffer size for now,
that's fair enough. I do hope the core issues can be resolved at
some point before final though, because the excellent system timing
is such a great feature of the BeOS platform, and a must-have feature
for serious audio and MIDI eventually!


I wrote a really crude "timing test" program for BeOS a while back,
that might work unmodified under Haiku:

http://knothole.no-ip.org/timingtest.zip

It's mostly concerned with measuring the inaccuracy of the snooze()
function under varying system load conditions. It does involve
real-time threads, so better save any work before running in case
it goes run-away...

Not sure if it's of any use in this case, but in the past I've found
it useful to pin-down timing issues.
For reference, on this machine the typical figure is about 20us
jitter, rising to about 50us under "adverse" conditions. My previous
machine (single-CPU Athlon 1330) was more like 50-200us; about the
maximum acceptable level before subtle timing problems with MIDI
begin to appear.


> BTW, your findings with the input/output rates being locked to each
> other could also be a problem in the multi-audio node.

Yeah, I'm a bit suspicious of the multi-audio-addon, especially
after the most recent test results, but unfortunately I've had a bit
of trouble trying to isolate it. I downloaded and compiled the Haiku
multi-audio-addon (which required adding a strlcpy implementation),
but upon restarting the media kit, no sound card appeared.

So for some reason the Haiku multi-audio-addon isn't loading, or
isn't recognizing the sound card driver -- is it supposed to be R5
compatible at present?


> Maybe it's an option to apply your change to force the driver to
> 44100 for the time being. I can imagine that it would cover up a
> pretty wide range of Haiku use cases.

This would definitely be useful as a last-resort, but I noticed the
driver does seem to have some kind of mechanism to allow a specific
sample rate and buffer size to be requested when it's opened.

Do you think exposing these settings in the media kit mixer would be
more involved than simply adding a few pop-up lists and an ioctl()
call?

If there are complications, how about a configuration file containing
sample rate and buffer size, much like the "emuxki" driver?


Ryan Leavengood <leavengood@xxxxxxxxx> wrote:
> So maybe you can just dig into the code some more and see what you
> can fix.

That's the plan! :)

To be honest, I'm not totally sure what I'm doing yet -- apart from
reading the codec datasheet, HDA is a new subject to me, and I'm
unfamiliar with the way the driver is put together.

However I'm quite interested in getting this thing working, so I'll
keep fiddling around with it until either it works, or never will
again!

I think it's actually pretty close now; just a few more recording-
related issues remaining; I'll get into that in a moment.


> I think a lot of us have HDA hardware, so getting that working well
> on Haiku could be very beneficial. Maybe that could be the
> "standard" recommended audio hardware that we can be sure runs 100%
> in Haiku (well maybe a few specific HDA chipsets to keep it
> reasonable.) That way we can flesh out all the media kit bugs
> before working on other audio drivers.

That sounds like an excellent plan, Ryan. I've always felt driver
diversity is quite a dangerous thing unless you have the resources
to support all the drivers perfectly!

HDA does look like a pretty good candidate for a "primary" audio
driver of sorts, owing to its widespread nature and flexibility;
a good low-to-mid range choice.

The next real step up, bypassing the low-end-disguised-as-high-end
stuff like Creative Labs, would be the cards from Echo and m-audio.
I think we have drivers for a lot of these too; not sure exactly
how far developed they are?



Anyway, now some more test results:

It struck me today that all the tests so far had been performed
with a bit depth of 24, and I vaguely remember seeing a similar
piece of code in the driver which reports the various supported
bitrates.

So, I commented out all the bit depths except 8- and 16-bit, which
forced the driver to operate at 16-bit.

This made a significant difference! Output still worked as normal,
but now recording worked much better -- it would always record,
with any sample rate selected between 44.1kHz and 192kHz.


The recording, however, was not always perfect. At the driver's
default 192kHz setting, the recording sample rate was still reported
as 192kHz (which might be a multi-audio-addon issue), however the
ADC on the card isn't capable of this rate.
Instead, recording took place at 96kHz, so the recording was sped up
by twice.

Lowering the speed of the recording resulted in what seemed to be an
acceptable quality recording. I haven't checked sound quality very
closely yet (so I don't know if the high frequency loss problem
still exists), and there is still background noise from the other
inputs. There is also a very small DC offset present (possibly from
the microphone inputs?).

However, the channel gain mismatch seems to have disappeared, and
the "wrap-around" problem has also gone -- both channels clip
naturally when over-driven.

I tried a few other sample rates, and this is where I encountered
some problems. On most sample rates, recording buffers appear to be
corrupted, or being periodically dropped. The result sounds like
the audio is playing back at the correct pitch, but literally
time-compressed (sped up in tempo) because of the missing buffers.


Not all combinations were affected however. Here's a table:

(might need to paste this into a larger StyledEdit window and
edit it -- the formatting might not survive e-mail. If anyone
wants an alternate copy, let me know.)


Base rate = Selected base rate in kRates[] array.
Multiplier = Selected multiplier in kRates[] array (divider is 1 for 
all these tests).
Actual playback = Measured playback rate (by comparing the pitch of 
test-tones, ignoring reported sample rate).
Actual record = Measured recording rate (by comparing the pitch of test
-tones, ignoring reported sample rate).
Skipped buffers = Were any audible discontinuities or lost/corrupted 
buffers audible in the recording?

Base rate       Multiplier  Actual playback     Actual record   Skipped 
buffers?
48000       4       192000          96000**     No
44100       1       44100           44100       Yes
48000       1       48000           48000       Yes
48000       2       96000           96000       Yes
44100       4       176400*         44100**     No
44100       2       88200*          44100**     No

[tested increasing the buffer size to 4096 with no improvement -- 
buffers are still missing on
recording:]

Base rate       Multiplier  Actual playback     Actual record   Skipped 
buffers?
44100       1       44100           44100       Yes

[tested decreasing the buffer size to 64 with no improvement -- buffers 
are still missing on
recording:]

Base rate       Multiplier  Actual playback     Actual record   Skipped 
buffers?
44100       1       44100           44100       Yes

[tested with R5 media kit mixer instead of Haiku mixer with no 
improvement --
identical-sounding missing buffer behaviour:]

Base rate       Multiplier  Actual playback     Actual record   Skipped 
buffers?
44100       1       44100           44100       Yes

[tested setting the divider to 2 (all the above tests are with the 
divider set to 1), with multiplier
at 2 -- no improvement, and now the output has terrible aliasing:]

Base rate       Multiplier  Actual playback     Actual record   Skipped 
buffers?
44100       2       44100 (poor)        44100       Yes



* = The DAC doesn't officially support this rate, but it seems to work 
fine anyway.

** = The ADC doesn't officially support the rate that would result from 
the base and multiplier, which might explain the unexpected resulting 
rate.



All of the above tests were performed with 16-bit audio. A few
spot-checks were made with 20-bit selected, and no major difference
was noted. The combinations which gave functional recording also
worked fine at 20-bit, and the combinations which skipped buffers
also produced skipping at 20-bit. The skipping, when present, did
seem to be more intense at 20-bits -- either more buffers lost, or
larger parts of each buffer being affected.

I'm not sure if there's any pattern to the "buffer skipping" -- it
almost sounds like they're dropped at random (tempo of recorded
music varies erratically), but it's hard to measure accurately.

However the buffer "skipping" does not appear to be related to
system load or interrupt timing -- stressing the system makes
no difference to the sound or pattern of dropouts at all, and
increasing the buffer size to extremely large values still causes
missing buffers.


One pattern that seems to emerge is that recording only works
correctly (no skipped buffers) when a sample rate which the ADC
*doesn't* support is requested!
(e.g., 48000x4 = 192k = too high, 44100x4 = 176.4k = too high,
44100x2 = 88200 = not 44.1k 48k or 96k which are the only
officially-supported rates for the ADC).

It's as if selecting an out-of-range rate causes the driver or
hardware to "fall back" onto a lower supported rate, and in the
process somehow enable flawless recording, while selecting that
same rate manually causes skipped buffers.


Note that the output does *not* fall back when an "illegal" rate
is requested, and actually operates at the requested rate!
Output seemed to be working quite successfully at 88.2kHz and
176.4kHz using this method, while the codec datasheet -- and codec
itself -- does not acknowledge these modes as being supported.


So, overall, using 16- or 20-bit instead of 24-bit changes a lot
of results on the recording side. I'm still not quite sure what
to make of all this though! It looks like a lot of the "clipping"
and "wrap-around" issues were related directly to the bit depth,
so might be confined to the multi-audio-addon. However it seems that
the sample rate and skipping behaviour may be specific to the driver.

I'd like to track down exactly what's happening differently between
the input and the output to explain this "fall back = success, force
rate = skip buffer" behaviour, but I'm not really sure where would be
best to start looking.

Any suggestions -- no matter how trivial -- from anyone who's fiddled
with these parts of the driver before would be really valuable!

Other related posts: