[haiku] Re: haiku HDA (audio) driver - feedback
- From: "Cyan" <cyanh256@xxxxxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Fri, 02 Jan 2009 19:16:31 GMT
"Jérôme Duval" <korli@xxxxxxxxxxxxxxxx> wrote:
> I added some code to activate EAPD on pins which have this
> capability (available in r28839)**. Maybe it would help in your
> case.
Okay; I'll report back when I've tested the latest version.
> Yeah, SoundRecorder is only ok atm (R5 and Haiku) with 16 bits
> data. Support for 24 bits (which the HDA format chosen) is still
> to be fixed and tested.
Ah, that explains it then. I've got another app that can do recording
in various formats somewhere, so I'll test with that one next time...
> I have problems with writing 24 bits WAVE files with correct
> paddings and well played afterwards.
Hmm, I recently wrote some code for handling 24- and 32-bit WAVE
files for another project, and I noticed the official spec is very
strange regarding this...
Specifically, are you writing a WAVE_FORMAT_EXTENSIBLE file?
(type code set to fe ff, 40 byte header chunk, FACT chunk present)
For some strange reason, Microsoft's spec requires this for any
bit-depth greater than 16, but some applications choke on the format
(including VLC for e.g. 32 bit float format).
Reverting to the "classic" format (16 byte header chunk) seemed to
fix the compatibility problems for me, and 24-bit worked okay --
each sample was written as three bytes little-endian with no padding.
Also 32-bit PCM worked okay in the classic format, with the least
significant byte set to zero (so really 24-bit left-aligned within
32-bit longwords).
There's another headache with the wBitsPerSample and nBlockAlign
fields -- as far as I can tell these always need to reflect each
other, even if padding is added. In other words:
(fixed font table)
Format | Channels | wBitsPerSample | nBlockAlign
----------------------+----------+----------------+------------
16 bits | 2 | 16 | 4
24 bits no padding | 2 | 24 | 6
24 bits padded to 32* | 2 | 32 | 8
32 bits | 2 | 32 | 8
* = Padding added as the first byte of each sample (LSB),
note it's identical to the header format for 32 bits.
Don't know if that helps any, but I've had trouble playing files
which don't adhere to this "guideline" (the official spec seems to
be ambiguous on the matter).
Have you got any examples of non-playing 24-bit files that I could
check out? I've got some examples in various compliant- and
non-compliant formats here if that'd help at all.
(regarding driver sample rate)
> This would be an unimplemented feature of the multiaudio media
> addon: proposing sample rate and format listbox to be used on the
> next start or live.
Would it be difficult to hard-code it to 44.1kHz for the time being?
I think that'd work out much more useful and certainly better quality
for most users...
> I don't see yet how the media mixer really helps here. It's all up
> to the driver to expose a 6-channels stream or multiple stereo
> streams (for outputs).
Well, I meant that the media kit mixer already has routing
facilities -- so e.g. application A can be sent to front-left and
front-right, while application B can be sent to rear-left and
rear-right.
If the driver could expose a 10-channel stream (or even 6-channels
would still be useful), it seems that apps should be able to take
advantage of this right away. Which would be extremely useful for
users like myself and Dane -- the key feature of HDA in both our
cases is the multi-channel I/O.
It could really be one of the killer apps for Haiku multimedia too:
not only are there enough outputs to run a fairly big audio mix into
a physical mixer, but -- crucially -- there are enough independent
inputs to record a drum kit. Currently this requires some pretty
expensive audio hardware to achieve, even under mainstream operating
systems.
> Thanks so far for your testing and feedback. It's definitely
> appreciated.
You're welcome!
Other related posts:
