"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!