Login at Kodi Home

gnif · 2010-09-20, 05:48

Hrmm, I have a card that reports the same thing, 24bit max, but alsa can open in 32... perhaps alsa is expecting S24 packed into S32.... I will investigate.

bobb0 · 2010-09-20, 06:04

gnif Wrote:Hrmm, I have a card that reports the same thing, 24bit max, but alsa can open in 32... perhaps alsa is expecting S24 packed into S32.... I will investigate.

Actually, I think you're spot-on. See here: http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html

PCM formats

The full list of formats present the snd_pcm_format_t type. The 24-bit linear samples uses 32-bit physical space, but the sample is stored in low three bits. Some hardware does not support processing of full range, thus you may get the significant bits for linear samples via snd_pcm_hw_params_get_sbits() function. The example: ICE1712 chips support 32-bit sample processing, but low byte is ignored (playback) or zero (capture). The function snd_pcm_hw_params_get_sbits() returns 24 in the case.

gnif · 2010-09-20, 07:27

I have added a check for this, and hopefully fixed S24 format issues, I cant test here however, can you please update and re-test.

We now try the formats in the following order...

FLOAT
DOUBLE
S24NE3
S24NE
S32NE
S32BE
S32NE
S16NE
S16BE
S16LE
... etc

if S32 is chosen, and sbits is 24, we use S24NE which converts to S24 and packs into 4 bytes.

gnif · 2010-09-20, 09:24

The clipping issue may be libmad, it seems to be returning samples > 1.0f and < -1.0f, I am looking at a solution right now, might have to implement a tanh soft clipper.

jmarshall · 2010-09-20, 10:50

libmad definitely can return abs(sample) > 1, yup. Check what used to be in mp3codec et. al. - IIRC we simply hard clipped after replaygain, but I may be misremembering Wink

gnif · 2010-09-20, 11:03

We used to output S16 and clamp, but when outputting float, clamping produces crap output at high levels. I have added a simple tanh soft clipper which works well, which I pinched from the audacity project. I am about to replicate it into dvdplayer.

bobb0 · 2010-09-20, 13:59

I recompiled with your changes. On startup it still selected 32bit output by default. Tested anyway.. the sound was awful.

Commented out the 32bit format, recompiled. Sounds much better.

It still skips over the 24-bit format though.

Gotta go to work... I will look into it more when I get home.

d

gnif · 2010-09-20, 14:09

Can you please post a log, and also please note, I fixed some pretty major issues in the last few updates, make sure you got the latest version again Smile

bobb0 · 2010-09-20, 19:47

I'll do a full wipe + checkout tonight.

jmarshall · 2010-09-20, 23:16

A soft limiter should not ever be used at the codec level unless the codec itself specifies that it should be. If anything, limiting should be done only after volume deamplification (replaygain/volume control etc.) has been done - it should always be the last thing in the chain.

I'm sure the libmad folk will be happy to let you know the appropriate way in which output from mad should be handled.

Cheers,
Jonathan

gnif · 2010-09-21, 02:06

jmarshall Wrote:If anything, limiting should be done only after volume deamplification (replaygain/volume control etc.) has been done - it should always be the last thing in the chain.

Good point! I will make the adjustments, will also contact the libmad devs

bobb0 · 2010-09-21, 02:47

Recompiled from a fresh checkout.. well, "rm -rf * && svn up"
No dice. Still initializes at 32bit according to the log. And clips like craazy.
"Boost on downmix" is OFF by default.
I haven't checked the ReplayGain settings, but I'm sure its at album levels as that is the xbmc default and this is a fresh install (new ~/.xbmc too)
Debug log: http://pastebin.com/4Yee0AYm

Very interesting.. the card is letting you set S32_LE so it must "support" it.. but the sound in that mode is.. well, not so good :/

I am going to have to add some additional debug to find out what snd_pcm_hw_params is actually returning.

Also, here is my /proc/asound/card0/codec#3 (the details of the hdmi out)
http://pastebin.com/DU5JRxdq

gnif · 2010-09-21, 02:55

thats very strange, it could be the function that converts 32bit to float.
I can also tell you why your device supports 32bit... your using "plug:hdmi", not the "plug" as the device, the "plug" plugin does format/samplerate, etc, conversion, you could try setting "custom" as the device and just putting in "hdmi" and see how that goes.

bobb0 · 2010-09-21, 03:57

Interesting point. I tried using custom and entering hdmi there -- no use, the code in AESinkALSA.cpp doesn't account for a custom device, instead it just detects hdmi and renames it to 'plug:hdmi' anyway -- I had to remove plug: from the code.

No change. Outputting directly to hdmi without the plug interface makes no difference.
Checked my crossfade/replaygain settings and made sure to disable them... no effect.

If I comment out 32bit mode, the next mode it selects is 16bit which sounds decent, some clipping but for the most part clean.

Is there something I can use to probe my audio hardware... outside of /proc?

OH, and alsa is reporting 32 significant bits, so it's not 24 being initialized as 32.

gnif · 2010-09-21, 04:28

sorry, forgot to mention that the device string has an extra specifier, the sink... try "alsa:hdmi"... it does not explain the clipping however, I am investigating what i think is a related issue atm.