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)



- koko1967k - 2012-01-22

shadow Wrote:According to the system info it is 11.0-pre

Hi,
Yes I know that the system info reports -PRE.
Inside the file "xbmc / xbmc / GUIInfoManager.h" it's reported that.

But I was asking if maybe the source has been updated and the GUIInfoManager.h hasn't been updated accordingly.

Should this not be the case, meaning that the eden version is really a PRE eden, then it would be interesting to know which svn version (and date) the latest gnif's release is based on.

I believe that this is important to know.


- gnif - 2012-01-22

@elite1967:
1) there is no build based on a svn version
2) your stuck with the version that was in GIT when I merged it last, I am not going to merge again any time soon unless there is a valid reason to do so for AE's sake.
3) It is not important to know, your playing with unsupported experimental code, if you cant deal with these issues, don't use it!


- koko1967k - 2012-01-22

gnif Wrote:@elite1967:
1) there is no build based on a svn version
2) your stuck with the version that was in GIT when I merged it last, I am not going to merge again any time soon unless there is a valid reason to do so for AE's sake.
3) It is not important to know, your playing with unsupported experimental code, if you cant deal with these issues, don't use it!

Hi gnif,
Please don't get me wrong... And my apologies if I haven't been clear. I really appreciate your work as all the work made by the whole development team. Smile Smile Smile

My question was related to the fact that since September a lot of things changed in Eden. In order to test the AE branch I think that we should test the final version, otherwise there is the risk that a bug already corrected in the master, is seen as bug in AE.

But this is just my thought of course and I could be wrong.

keep on your excellent work!


- sebak - 2012-01-22

elite1967 Wrote:Hi gnif,
Please don't get me wrong... And my apologies if I haven't been clear. I really appreciate your work as all the work made by the whole development team. Smile Smile Smile

My question was related to the fact that since September a lot of things changed in Eden. In order to test the AE branch I think that we should test the final version, otherwise there is the risk that a bug already corrected in the master, is seen as bug in AE.

But this is just my thought of course and I could be wrong.

keep on your excellent work!

Well, afaik AE is build from the ground up so it has nothing in common with the audio code in eden. So if an audio bug is found in AE, it has not yet been corrected in eden and if another kind of bug is found in AE, it's not to AE to deal with it.


- rodercot - 2012-01-22

I spent a bunch of time yesterday and this morning building up a new test machine. It is fresh 10.04 LTS updated latest kernel EVERYTHING works in linux including suspend/resume from both cli and remote in and out of mythbuntu (audio functions fine when resumed from mythbuntu as well). here is a syslog of the errors in XBMC coming in and out of suspend in AE. I have tested this now with a gt 220 and now a gt 240. This is not playing back a file this is just suspend and resume - so far onto testing files to see about the audio dropout issue. I have a new mediaserver as well serving some files and they are on the same 1GB switch in the same room. I have pass-through disable as you can see in the log and dwnmx to 2CH on my asus 1080p 24" monitor.

I should also note that suspend resume only will work once after a fresh boot on the 2nd attemp it crashes to the desktop I have played with this on both confluence and rapier (SVN)

http://pastebin.ca/2105077

Regards,

Dave


- gnif - 2012-01-23

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

@gnif Just caught up with your last changes lol. What platform are you developing/testing on?


- gnif - 2012-01-23

@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

Excellent - cause I'm busy filling in some Windows issues. At least their complimentary Wink

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

@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

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

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.

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.

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 Laugh


- gnif - 2012-01-23

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

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).

The hard-coded sample rate and channel layout are for when there is no available streams to determine this information from.

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

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

Code:
CSingleLock streamLock(m_streamLock);
  bool wasEmpty = m_streams.empty();
  CSoftAEStream *stream = new CSoftAEStream(dataFormat, sampleRate, channelLayout, options);
  m_streams.push_back(stream);
  streamLock.Leave();

  if (AE_IS_RAW(dataFormat))
    OpenSink();
  else if (wasEmpty || !m_preferSeemless)
    OpenSink();

Note that OpenSink is called AFTER the new stream has been added to the m_streams vector.

Code:
/* if we dont have a master stream, choose one based on the seemless setting */
  if (!masterStream && !m_streams.empty())
    masterStream = m_preferSeemless ? m_streams.front() : m_streams.back();

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.

Code:
/* the desired format */
  AEAudioFormat newFormat;

  /* override the sample rate & channel layout based on the master stream if there is one */
  if (masterStream)
  {
    newFormat.m_sampleRate    = masterStream->GetSampleRate();
    newFormat.m_channelLayout = masterStream->m_initChannelLayout;
    /* dont resolve the channels if we are transoding or in raw mode */
    if (!m_transcode && !m_rawPassthrough)
      newFormat.m_channelLayout.ResolveChannels(m_stdChLayout);
  }

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:

FLOAT
DOUBLE
S24NE3, S24LE3, S24BE3,
S24NE4, S24LE4, S24BE4,
S32NE, S32LE, S32BE,
S16_NE, S16_LE, S16_BE,
S8
U8

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.