+- 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-27
gnif Wrote:Seems like the endian is not getting swapped correctly for your system... what is your CPU?
Mainboard: Jetway NC62K features an onboard GeForce 8200 (MCP78S HDMI Audio)
CPU: AMD X2 AM2+ 5400 Low-Power (65W)
Hold on.. it gets even weirder... I'll report back later.
- gnif - 2010-09-27
thats a little endian cpu, it should be working fine... and it should be working with S32_LE and speaker-test, id say you have a driver/configuration problem un-related to xbmc.
- bobb0 - 2010-09-30
yea, the more i digged into that, i found it was still outputting S16_LE.
anyway, I've done a little more experimenting.
I removed the ALSA_OPTIONS: NO_AUTO_CHANNELS | NO_AUTO_FORMAT | NO_AUTO_ RESAMPLE
So now it simply initializes the output as FLOAT and lets ALSA choose the best output format and do what it needs to do. Interestingly, it chose S32_LE as the output format on its own as discovered by 'cat `find /proc/asound/card0/pcm3p/sub0/*`' but you may be interested to know that the sound as as good as when I had disabled S32_LE and forced it to use S16_LE
What this tells me is that you are right.. we need to look into the whats happening in the conversion to float and from float. To float seems to be introducing small amounts of clipping, and from float to 32 is where the major amount of clipping is occurring.
Another thing I've noticed is that my S32_LE issues seem to stem from forcing RW_INTERLEAVED. When I ran speaker-test, I found it would automatically choose MMAP_INTERLEAVED. This is confirmed by the 'good' output @ S32_LE with the changes I described above. ALSA automatically selected MMAP_INTERLEAVED.
Here is the output of 'cat `find /proc/asound/card0/pcm3p/sub0/*`':
antigenx@xbmc:~/xbmc-ae$ cat `find /proc/asound/card0/pcm3p/sub0/*`
Code:
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 352
buffer_size: 11264
card: 0
device: 3
subdevice: 0
stream: PLAYBACK
id: NVIDIA HDMI
name: NVIDIA HDMI
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 0
4096
32768
state: RUNNING
trigger_time: 3096.920748227
tstamp : 3430.389582743
delay : 10838
avail : 426
avail_max : 11178
-----
hw_ptr : 14705974
appl_ptr : 14716812
tstamp_mode: NONE
period_step: 1
avail_min: 352
start_threshold: 2147483647
stop_threshold: 11264
silence_threshold: 0
silence_size: 1476395008
boundary: 1476395008I also played around with the buffer calculations, but they seem fine to me. I wish I knew more about audio conversion from one bit format to another... do you have any references you can direct me to?
- lloydsmart - 2010-09-30
I don't really have anything useful to input here, but I just wanted to say keep up the great work - this is something that really needs to be done for xbmc and will make it even more awesome than it already is. Thanks!
- gnif - 2010-09-30
Those options stop ALSA from converting to what the card actually supports, so your introducing another conversion by remove the options.
Conversions are simple math, float samples are -1.0f to 1.0f.. say we are converting from U8... 8bits can store 0-255, so.. we do this...
Code:
float sample = (value / (255 / 2)) - 1.0fCode:
float sample = value / (255 / 2)Code:
float sample = value / (65535 / 2)The other direction is just the reverse..
Code:
int8_t sample = value * (255 / 2)It gets a little more complex when endian comes into it, and we use SIMD instructions to increase performance, but thats basically what we are doing. For 8bit and 16bit we use a lookup table as it is faster then calculating those values, but due to the >4 million possible values for 32bit, we can not create a lookup table for it.
- bobb0 - 2010-10-03
I found a resource that may be helpful.
http://www-mmsp.ece.mcgill.ca/Documents/Downloads/AFsp/
parent: http://www-mmsp.ece.mcgill.ca/Documents/Software/index.html
- gnif - 2010-10-03
I dont understand how these could be helpful, they are conversion programs, the issue is nothing to do with your source audio, it is with the conversion from float, to whatever your card wants... or with your card itself. The only way I can replicate to test is to obtain a card that supports the same format as yours... if the output is ok, it will mean it is a driver/card issue.
- bobb0 - 2010-10-03
I've ruled out any card/driver/hardware issues.
I've performed the same operations on the source audio manually (S16-->FLOAT-->S32) and output the resulting file using aplay -fS32_LE -vv -Dplug:hdmi (and -Dhdmi)
The audio was flawless and was output in S32_LE as expected using the same method as currently used in the AudioEngine code.
- gnif - 2010-10-06
I managed to replicate on a friends computer and I have found the issue, the MathUtils::round_int function cant round >= INT32_MAX / 2... it overflows... I have committed a fix, and it has corrected the distortions here for me.
- tooshna - 2010-10-11
Like Mac users have already figured, there's no Dynamic Range Compression (DRC) in Xbmc. Attaining DRC should not require to remix a movie: it is about making the softest sounds louder and the loudest sounds softer, so that when you for example rise the volume to hear someone whisper in a dialogue, you don't next get blasted by some special effect or music. Addressing this aspect of sound will show some respect to your ears and to your loudspeakers. Im only using the stereo speakers attached to my TV so i cant do the centre speaker trick on my mac mini. I was watching mars attacks on tv tonight and the sound equalisation was perfect, but then i tried watching my file of it through xbmc and the speech was so soft but the guns blasting were loud as hell. Xbmc really needs drc implemented. A lot of people on these forums want it too, as many have said, having to ride the volume up and down throughout the movie kills the experience.
- firnsy - 2010-10-11
tooshna Wrote:Like Mac users have already figured, there's no Dynamic Range Compression (DRC) in Xbmc ...
We get, it you want DRC. Please stop cross posting and submit a detailed ticket so it can be tracked.
If you have a patch that implements DRC in AE then by all means disregard this interject and continue your discussion. Otherwise this thread is in the development section. Please read the description of the Development sub forum on what should be discussed in these threads.
- gnif - 2010-10-12
DRC is planned, and has already been mentioned in this thread, and is NOT a priority at this point.
Time for another update!! I am very excited to announce that AC3 encoding is now working, and seems for the moment to be quite stable, there is no up-mixing yet so mono/stereo sources wont have a center channel, but this is easy to fix compared with just making AC3 encode work at all.
I am calling it "encode" not "transcode" here for a very good reason, the encoded is implemented at the END of the audio pipeline after mixing in the streams and the gui sounds, and after de-amp, which means... XBMC is running FULLY in AC3, not just the music and video output.
This is a huge milestone, and suffice to say, I am very very excited about it.
- lloydsmart - 2010-10-12
Fantastic! Well done gnif and anyone else who may have worked on this! I'm sure everyone really appreciates all your hard work on this, I know I do. Keep it up! What's the next step/target?
- gnif - 2010-10-12
On the list:
* Fix encoder delay calcs (Just committed this, but not tested)
* Provide option and capability to upmix
* Add LADSPA support or add low-pass filter, not sure which way I will go yet
- Harry Muscle - 2010-10-12
gnif Wrote:On the list:
* Fix encoder delay calcs (Just committed this, but not tested)
* Provide option and capability to upmix
* Add LADSPA support or add low-pass filter, not sure which way I will go yet
Adding LADSPA would be quite a nice addition. If you're interested in help I might be able to offer some once I'm done with implementing Slingbox support for XBMC. Btw, what do you mean by low-pass filter? How is that an alternative to LADSPA?
Btw, is that the complete To Do list, or is there more stuff left to be done on the AudioEngine?
Thanks,
Harry