Kodi Community Forum
AudioEngine branch - DO NOT REQUEST BINARY BUILDS - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+--- Thread: AudioEngine branch - DO NOT REQUEST BINARY BUILDS (/showthread.php?tid=78289)



- bobb0 - 2010-09-22

Compiled with your most recent changes tonight.
Is there anything else that may be useful to you? I could proc /proc/asound/card0/pcm3p/sub0/*

I wish there was a way to attach some kind of VU meter to the sink.. The only other possibility is that it's a buffer underrun noise, but IIRC that would be a more consistent type noise, wheras this is definitely in the bass freq range, which tends to make me think 'clipping' more than latency/buffer issues.


- bobb0 - 2010-09-22

I commented out the 32bit option in the code.. I'm listening to the output for clips in 16bit output mode. So far so good but I will keep you up to date.


- bobb0 - 2010-09-22

I noticed an improvement, or at least I thought I did... until I listened to A Perfect Circle - Judith. There is still heavy amounts of clipping even when in 16bit output. I also disabled the visualization to ensure that maximum processing power would be available to alsa (2.6GHz AMD AM2+ LowPower processor). Just to be sure I'm not crazy I'm going to listen to the same file on another PC with some good speakers, but I'm pretty sure these clips are not present in the source.

IN S16NE --> FLOAT --> OUT S16NE


- gnif - 2010-09-24

I believe I have found part of the issue, there was a bad calc on the amount of data written, bufferers were getting messed up, try with the latest and 32bit, it hopefully is fixed now

it had: bytes = samples * bytes per frame

thats going to cause issues! esp if the output bytes per frame != bytes per sample, which would have been the case in anything except 2ch S16


- bobb0 - 2010-09-25

No perceptible difference. To be sure, I rm'd the entire source, svn up and recompiled.


- bobb0 - 2010-09-26

I've been trying to think of the best way to probe ALSA to see what's happening during playback. The only thing I can think of is to cat /proc/asound/card0/pcm3p/sub0/* while playing back audio.

I did this while playing the same piece of audio using the svn-ppa version of xbmc and a compiled AudioEngine version.

You can compare the files here: http://pastebin.com/gYx8kVuZ

Update: deleted a bunch of useless stuff from this post. I realize now that you are actually using double the number of periods that alsa uses by default. Anyway, I hope those logs will help... I'm just tracing through all your code in an attempt to understand it Wink


- bobb0 - 2010-09-26

I just realized something.... what if the problem is not AE/ALSA but my receiver?

Just because the card can output S32_LE PCM, doesn't mean my receiver can accept and process it properly... Crutchfield says it does.. Onkyo HT-R670 The manual confirm's Crutchfield's page.
Quote:Supported Audio Formats:
• 2-channel linear PCM (16/20/24 bit/32–192 kHz)
• Multichannel linear PCM (7.1 ch, 32–192 kHz)
• Bitstream (DSD, Dolby Digital, Dolby Digital Plus, Dolby TrueHD, DTS, DTS-HD High Resolution Audio,
DTS-HD Master Audio)
Your DVD player must be able to output these formats from its HDMI OUT.


But I don't fully trust that information considering manuals from foreign companies are rife with errors a lot of the time.

This guy over at Hydrogen audio has the HT-R670 hooked up to his PC via HDMI in Windows7 and he says it reports the maximum supported bit-depth as 24-bit.

So now it becomes a question of not only what can the card output, but what can the receiver accept, and is there a way to detect that? I'm certain that information is probably available via the edid, but tools like parse-edid tend to ignore the audio-format portions of the edid.


- topfs2 - 2010-09-26

I read that as 16,20 and 24 bit in 32-196khz. Not 32bit. ?


- liquidskin76 - 2010-09-26

gnif Wrote:and if someone is kind enough to donate the hardware, true-hd, etc... (i only have spdif hardware).

Not sure if you've already had a suitable offer yet? Is that TrueHD decoding or TrueHD/DTS-HD bitstreaming?

I can help test both if required. Been using DSPlayer/ffdshow for HD audio bitstreaming.

Cheers


- bobb0 - 2010-09-26

topfs2 Wrote:I read that as 16,20 and 24 bit in 32-196khz. Not 32bit. ?

I think you're right. So ALSA wants either 16-bit or 32-bit and the receiver wants 24-in-32. Looking at the ALSA code, I see they force S32_LE and S16_LE as the only 2 supported bit formats (see: alsa-kernel/pci/hda/patch_nvhdmi.c)

On a wing and a prayer I tried changing the alsa source to support S24_LE but to no improvement (though AE did select S24_4LE which is nice to see.) For now I guess the best solution is to restrict S32_LE output until I understand the hardware end a bit more.


- gnif - 2010-09-27

bobb0 Wrote:ALSA wants either 16-bit or 32-bit and the receiver wants 24-in-32

Hehehe, I believe you have missed the point here... analog audio, is analog, bits dont matter... if its uncompressed PCM via SPDIF, then the sound card will format it accordingly as SPDIF is a standard, otherwise it wont work at all, and the card does not support SPDIF.

Unfortunatly we are at the point where I need to replicate your setup to further diagnose the issue, or you need to try to track it down... disabling output formats is NOT the solution, and a hack for this wont be implemented, there is an issue elsewhere, possibly in the convert functions, or buffering code, look there for the problem.


- gnif - 2010-09-27

you can test outside of XBMC

Code:
speaker-test -FS32_LE -twav



- bobb0 - 2010-09-27

gnif Wrote:Hehehe, I believe you have missed the point here... analog audio, is analog, bits dont matter... if its uncompressed PCM via SPDIF, then the sound card will format it accordingly as SPDIF is a standard, otherwise it wont work at all, and the card does not support SPDIF.

Analog?


- bobb0 - 2010-09-27

gnif Wrote:you can test outside of XBMC

Code:
speaker-test -FS32_LE -twav

Good point. What I found was if I try to force S32_LE the sound stutters like mad, but with S32_BE output is golden.


- gnif - 2010-09-27

Seems like the endian is not getting swapped correctly for your system... what is your CPU?