AudioEngine branch - DO NOT REQUEST BINARY BUILDS - Printable Version
+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Development (/forumdisplay.php?fid=93)
+--- Thread: AudioEngine branch - DO NOT REQUEST BINARY BUILDS (/showthread.php?tid=78289)
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133
- gnif - 2012-01-23 07:14
Time for another update...
* Better thread synchronisation in CSoftAEStream
* Added new CAEStream::RegisterSlave so streams can be slaved to resume when one finishes draining
* PAP updated to use CAEStream::RegisterSlave, gapless playback is now frame exact.
Pulse audio is possibly broken from this update, have not had time to test it yet, there may be a deadlock caused by these changes, pulse is pretty temperamental with thread synchronisation.
- DDDamian - 2012-01-23 07:34
@gnif Just caught up with your last changes lol. What platform are you developing/testing on?
- gnif - 2012-01-23 07:43
@DDDamian - Debian, Ubuntu and ArchLinux. I don't touch the other platforms, but I provided the abstraction required to allow others to develop the code for those platforms (eg, DirectShow, WASAPI).
- DDDamian - 2012-01-23 07:51
Excellent - cause I'm busy filling in some Windows issues. At least their complimentary
One thing I've noted is the code in SoftAE tends to try maintain a constant sample rate, number of channels etc. I'm looking at it from the point of trying to present the original source data to the receiver, at the expense of closing and opening sinks more frequently if required.
That cause any concern for you?
- gnif - 2012-01-23 09:12
@DDDamian - Are you able to get on IRC to discuss this? I thought that this was all working correctly.
Actually, looking more, there is an option to enable the behaviour your looking for... set m_preferSeemless to false.
Re-opening the sink is a concern for most users, as not everyone is an audiophile, AE does its best to select the best possible format based on the client's hardware configuration. Video playback should always switch to the best possible format, paplayer is a different story as it may be switching between ac3/5.1/2.0 while cross fading, etc... but even still it does the best it can to match the formats if it can.
Setting m_preferSeemless forces the sink to be re-opened when the formats don't match, causing the output to be non seamless when formats change.
- DDDamian - 2012-01-23 09:25
Been ages since I did IRC but I'll set up a client and PM you the nick. Much better than the forum for sure.
Here's a general rundown of what I've found just for a heads-up (all Windows 7 x64 testing):
- lots of stuttering playing DTS-HD - buffering?
- WASAPI sink wouldn't open at all in Exclusive mode, only Shared
- sink wouldn't be reinitialized when changing from one channel-count to another playing Flacs e.g. going from 5.1 - 2.0 would stay 5.1 and vice-versa
- SoftAE:OpenSink() has some issues: should have AEAudioFormat structure passed to it, and some other issues with the logic for passthrough/transcoding
I've got a lot of it fixed up and a few changes made in a seperate GIT branch but still issues to work out. Some would impact on your code like the OpenSink() mods, so I didn't want to go further without talking to you.
It's 2:30am here GMT-5:00 (Toronto, Canada) so I'll leave the IRC setup till tomorrow, but yeah, it'd be nice to help a bit on the Windows side if you agree with what I've done.
- DDDamian - 2012-01-23 09:29
gnif Wrote:Re-opening the sink is a concern for most users, as not everyone is an audiophile, AE does its best to select the best possible format based on the client's hardware configuration. Video playback should always switch to the best possible format, paplayer is a different story as it may be switching between ac3/5.1/2.0 while cross fading, etc... but even still it does the best it can to match the formats if it can.
I'll look into that - I saw it there but thought that might be for gapless playback (although I see know where that's done). I changed the behaviour by tightening up the IsCompatible test to force the sink to close and re-open.
Same skin, different cat
- gnif - 2012-01-23 09:31
Quote: SoftAE:OpenSink() has some issues: should have AEAudioFormat structure passed to it
Explain why? The best audio format is decided by getting either the oldest stream's format, or if m_preferSeemless is disabled, the newest stream's format (see masterStream local var).
The hard-coded sample rate and channel layout are for when there is no available streams to determine this information from.
- DDDamian - 2012-01-23 09:42
gnif Wrote:Explain why? The best audio format is decided by getting either the oldest stream's format, or if m_preferSeemless is disabled, the newest stream's format (see masterStream local var).
OpenSink() makes a lot of decisions regarding handling the transition, with limited information available to it. Thus some of the hard-coded or best-guess numbers. I'd set it up that by reading the Exclusive Mode GUI radio button I could essentially create an audiophile switch in one of two ways: passing through raw PCM without the float conversion, or forcing the sink to close and re-open on change of bitdepth/sampling rate/channel count. The second method meant that AVR processing for two-channel sources could still occur even if multichannel proceeded it. Likewise it was responsive to going from 16-bit to 24-bit and back.
For those reasons I passed it an AEAudioFormat structure with all the details of the next stream.
- gnif - 2012-01-23 09:55
Quote:For those reasons I passed it an AEAudioFormat structure with all the details of the next stream.
This is already occurring, please see the below snippets
Note that OpenSink is called AFTER the new stream has been added to the m_streams vector.
If we are not in RAW mode the above code picks up the stream based on the preferSeemless setting, which if false, will be the new stream just added in MakeStream.
If we have a masterStream, get the deatils from it, which is exactly what that AEAudioFormat structure is that your trying to pass the method.
AE works in float, as does the visualizations, mixing, etc... this was an intentional design decision and any code that causes this conversion to float to be bypassed will be rejected due to the added complexity. Much work has gone into optimising the float conversion code on all platforms, including embedded platforms such as ARM with NEON extensions.
Because AE is working in float, the best possible output format is Float, if it fails to open that due to your hardware limits, your sink is supposed to try the next best until it finds a compatible format. So with ALSA it tries:
S24NE3, S24LE3, S24BE3,
S24NE4, S24LE4, S24BE4,
S32NE, S32LE, S32BE,
S16_NE, S16_LE, S16_BE,
In that order, ensuring it gets the best possible format on the hardware. I fail to see how passing the format would help since it is already determined by what the stream is using.
Also, Exclusive mode is windows only, and any platform specific code should NOT be in CSoftAE or CSoftAEStream, thats what the sinks are for.