+- 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: Testing audio engine ActiveAE (/showthread.php?tid=170338)
RE: Testing audio engine ActiveAE - xbmcaudio - 2014-02-28
Hello. I would like to share with you knowledge I have now. I'm experiencing troubles with ARCAM RDAC connected through USB. I'm using WASAPI. Trying to find what is wrong I tried JRiver few days ago. And I have to say that it plays perfect. I understood that everything is fine with USB cable, USB port and problem is somewhere else. Then I run Performance Monitor and selected performance counters for ARCAM RDAC. And Perfmon shown me what the problem is. At the moment when I heard delay/distortion I saw spike for "Transfer errors/sec" performance counter. I switched back to JRiver and it plays perfect again. But then I found that "Avg bytes/transfer" counter is higher when JRiver plays. I decided that sound buffer is bigger in JRiver and changed sound buffer from 100 to 50 msec. The "Avg. bytes/transfer" starts showing the same value as when XBMC plays. And of course I heard the same problems I heard when I use XMBC. I heard and I saw exactly the same delays/distortions and same "Transfer errors/sec" spikes. Thus, 100msec buffer will definitely solves all sound problem in my environment.
I can say more, when buffer length is 100 msec counter "Isochronous bytes/sec" looks like straight line. Value of counter is absolutely constant!!!! When buffer length is 50 msec value is floating (especially when transfer errors occur).
So, is it possible to return audiosinkbufferdurationmsec parameter or increase default sound buffer length from 50 msec to 100 msec?
RE: Testing audio engine ActiveAE - FernetMenta - 2014-02-28
I will look into it, maybe we can double the buffer size for USB devices.
RE: Testing audio engine ActiveAE - FernetMenta - 2014-03-01
@xbmcaudio could you test this and report back? https://github.com/FernetMenta/xbmc/commit/4eacd24d0b4a0ab4606ae3d555ffc2bf8971fc16
Currently I can't increase the buffer over 80ms.
RE: Testing audio engine ActiveAE - xbmcaudio - 2014-03-02
@FernetMenta I built it. And I'm testing it right now. Overall, result is VERY positive. But there is one interesting thing. When sample rate is 48KHz music plays well for 110-120 seconds and then I hear delay and see one Transfer error. Then, next 110-120 seconds sound is perfect and then again delay and one more Transfer error. And every 110-120 seconds there is "Transfer error". Sound is perfect between these Transfer errors. I chaned sampling rate to fixed 44.1 and I saw absolutely the same picture. The difference is that probablity of Transfer error is about 75%. But interval is the same 110-120 seconds. Then I changed sampling rate to 88.2 and during 16 minutes listening I saw only two Transfer errors, Now I set sampling rate to 96 and I see no Transfer errors last 14 minutes.
Overall, it sounds a way better. I mean it sounds great between these Transfer errors.
I'm going to check everything tomorrow. But this is what I can say now. Thank you, by the way.
RE: Testing audio engine ActiveAE - fritsch - 2014-03-02
Mmh, anything in the logs when those drops happen?
Can you check another usb port? updated driver?
RE: Testing audio engine ActiveAE - xbmcaudio - 2014-03-03
@FernetMenta Hello, I made some screenshots and debug log file.
XBMC 80 msec 96KHz
XBMC 80 msec 88KHz
XBMC 80 msec 48KHz
XBMC 80 msec 44KHz
And now to compare
Original XBMC 50 msec 48KHz
JRiver 50 msec 48KHz
JRiver 100 msec 48KHz
And I attached debug log for Original XMBC 48KHz. This debug log corresponds to the screenshot Original XBMC 50 msec 48KHz you see above.
RE: Testing audio engine ActiveAE - xbmcaudio - 2014-03-03
All results are with unchanged setup. USB port is the same, cable is the same. I just stop one application and start another one. I even run Performance monitor from remote host. So XBMC runs in foreground. If you look at (for example) 44KHz screenshot you'll see that average data rate is 264,253. That's actually fine because sample rate is 44100*2 channels*24bits per channel=264,600. But at the moments where Transfer error occurs data rate is about 222,500. And there is audible pause in playback.
I hope this helps. And thank you again.
RE: Testing audio engine ActiveAE - FernetMenta - 2014-03-03
What exactly does that mean? Still problems with 80ms buffer? How is 80ms compared to 50ms? What issues are lest?
RE: Testing audio engine ActiveAE - FernetMenta - 2014-03-03
I pushed 2 more changes to this branch: https://github.com/FernetMenta/xbmc/commits/wasapi
It increases buffer to 100ms.
RE: Testing audio engine ActiveAE - xbmcaudio - 2014-03-03
Yes, there are problems still. But I hear less audible delays. That's for sure. You can look at the Original XBMC 50 msec screenshot. You can see 8 Transfer errors during 500 seconds playback interval. And if you look at version with 80 msec buffer you'll see only 4 errors for the same 500 seconds interval. And each Transfer error means audible delay in playback. And high sampling rates (88 and 96) are almost free of delays now.
RE: Testing audio engine ActiveAE - FernetMenta - 2014-03-03
ok, I hope the 100ms buffer will cure the issue then. (and does not introduce new ones)
RE: Testing audio engine ActiveAE - xbmcaudio - 2014-03-03
I'm listening to new version last 40 minutes. I don't hear any audible problem with playback. I don't see any Transfer error. It plays perfect !!! I tried both 44KHz and 48KHz sources. XMBC plays just perfect!!!
Update
I didn't hear any problems with sound during whole day listening.
THANK YOU!!!!
RE: Wrapping Odd CH Layouts in 5.1 Clothing... - gjwAudio - 2014-03-13
(2014-02-28, 09:10)fritsch Wrote:Quote:For these reasons, I ask: is it possible to perform an output channel override/hack (in a config file somewhere) that will change ActiveAE behaviour only in the event of 4.0/4.1 input channels ? And use the native sample rate as found in the file ?
No.
Been trying to work with the advice offered last week (ie: switch to Fixed Audio Output), and if I had a dollar for every time I've been to the Settings screens, well... I could buy some really fancy A/V gear !
But seriously, I think I've asked the wrong question above. Better stated:
Request: Can you please change the xbmc audio output behaviour for 4.0/4.1 PCM audio, to match the current behaviour for 3.0 PCM.
That's all... just do the same thing as you do with 3.0 audio.
This should close the loophole which many/most HDMI-equipped ARVs now suffer: PCM audio over HDMI is either 2-CH, or movie-style 5.1/7.1-CH, and other configs are not recognized. We need to send 4.0/4.1 in a 5.1 "wrapper".
xbmc does this today with 3.0 audio, as seen in the following log excerpt:
Code:
INFO: CActiveAESink::OpenSink - initialize sink
DEBUG: CActiveAESink::OpenSink - trying to open device ALSA:hdmi:CARD=PCH,DEV=1
DEBUG: CAESinkALSA::GetChannelLayout - Input Channel Count: 3 Output Channel Count: 5
DEBUG: CAESinkALSA::GetChannelLayout - Requested Layout: FL,FR,FC
DEBUG: CAESinkALSA::GetChannelLayout - Got Layout: FL,FR,BL,BR,FC
INFO: CAESinkALSA::Initialize - Attempting to open device "hdmi:CARD=PCH,DEV=1"
INFO: CAESinkALSA::Initialize - Opened device "hdmi:CARD=PCH,DEV=1,AES0=0x04,AES1=0x82,AES2=0x00,AES3=0x0a"
INFO: CAESinkALSA::InitializeHW - Your hardware does not support AE_FMT_FLOAT, trying other formats
INFO: CAESinkALSA::InitializeHW - Using data format AE_FMT_S32NE
DEBUG: CAESinkALSA::InitializeHW - Request: periodSize 682, bufferSize 2730
DEBUG: CAESinkALSA::InitializeHW - Got: periodSize 910, bufferSize 2730
DEBUG: CAESinkALSA::InitializeHW - Setting timeout to 29 ms
DEBUG: CAESinkALSA::GetChannelLayout - Input Channel Count: 3 Output Channel Count: 6
DEBUG: CAESinkALSA::GetChannelLayout - Requested Layout: FL,FR,FC
DEBUG: CAESinkALSA::GetChannelLayout - Got Layout: FL,FR,BL,BR,FC,LFE
DEBUG: CActiveAESink::OpenSink - ALSA Initialized:
DEBUG: Output Device : HDA Intel PCH
DEBUG: Sample Rate : 96000
DEBUG: Sample Format : AE_FMT_S32NE
DEBUG: Channel Count : 6
DEBUG: Channel Layout: FL,FR,BL,BR,FC,LFE
DEBUG: Frames : 910
DEBUG: Frame Samples : 5460
DEBUG: Frame Size : 24The change/fix seems simple enough to me (who has no insight into xbmc audio internals), when you get 4.0/4.1, do what you already do with 3.0 - wrap it.
Am I missing some fatal flaw in this approach ?
Thank you again, for the huge effort in building the ActiveAE engine - I hope this observation will lead to making xbmc just a little more effective as a one-stop media center solution.
Cheers,
Grant
RE: Testing audio engine ActiveAE - FernetMenta - 2014-03-13
This happens when opening 3.0 FL,FR,FC
- you can't have gaps, in ALSA map FC is at pos 5
- only even numbers of channels are allow
This is why 3.0 opens as 5.1
4.0 as FL,FR,BL,BR is valid and most devices don't have issues with this. We can't just open 5.1 for this case.
RE: Testing audio engine ActiveAE - kyungrak - 2014-03-13
Having exactly the same issue, really annoying.
I've settled for now using dvdplayer, but since gotham, when audio files have art embedded, dvdplayer sees the file as a video stream and thus display the album art fullscreen, so don't have visualization anymore playing those files.
So no real solution, but I 'd rather have no visualization than to reboot my htpc each time it comes across a hi res file while playing in party mode.
(2014-01-01, 13:27)tarkus Wrote: Hi there,
This has been a problem on Party mode for ages now, I've mentioned previously in this thread but I'll mention it again as it is a critical bug (to me, and surely to many others also).
Problem:
In Party Mode, change of sample rate (eg. from 44.1/16 to 96/24) crashes XBMC. Hard reboot is required.
This is with the 'Best Matched' setting.
Log:
http://paste.ubuntu.com/6672649/
- XBMC crashed when changing from The White Stripes - Screwdriver (44.1/16) to The Rolling Stones - Rocks Off (88.2/24).
Please note that XBMC does not crash when an individual song is selected from the playlist, only when it advances by itself.
Thank you for all the hard work devs!