[fritsch]

I you change audio output to "Fixed" 5.1 48 khz - everything is fine for the same file. So decoding is file and even resampling it on the fly is no issue. I think it's something PI specific then (firmware).

[MrNice]

I did a Debug log, using PAPlayer.
First part screen was file mode: I had 3 drops during 1 minute. I noticed CPU0 was 98 to 100 % (Kodi 94-95 %)
Then I changed to full screen: I had plenty drops, every second for the rest of the time. I noticed CPU0 was 40 to 55%
http://xbmclogs.com/pdlsxhtup

Second play with DVDPlayer
NO DROP at all either in file mode or full screen mode, even dim.
CPU0 was the same as PAPPlayer in 2 modes.
I don't think you need the Debug log, let me know.

It's _not_ a Denon issue. It's an issue with the PI delivering that amount of data. I highly doubt your 512 Pi will be able to play those without issue over time. You most likely only have a chance with disabling VIZ alltogether, making sure nothing is scraped. Press c on the file and play with another player.

Do you think RPi512/PAPlayer can't play with passthrough on? (What I have).
With the second test it looks a player issue?

BTW, looking for info about the 2 players I found that (date: 23rd Mar, 2015, 01:51 AM). Read these 2 lines:
http://forum.xbian.org/thread-2877-post-...l#pid28473
Maybe there is a relation?

[fritsch]

5.1 flac is not passed through. Passthrough is AC3, DTS, EAC3 and (DTS-HD, TrueHD which is not available on the PI).

And btw. you are not Obi van Kenobi. If I request a Debug Log I want one.

See my tests above.

[fritsch]

Make that easy test:

Go to Audio Configuration, set Mode "Fixed", 48khz and 5.1 speakers. Now play the file again.

Edit: Something else. While you just quoted my private Mail, that I sent to you and to nobody else, even out of context. I think the Pi1 will struggle playing 96 khz 5.1 flac _when_ viz is turned on on top. If that works by chance it will start to stutter when you browse through your menus or fullscreen / non fullscreen is switched.

[MrNice]

Audio output: 5.1 Mode fixed 48kHz

Play with PAPPlayer, mode file
CPU0 98 to 100 % - Kodi 95 %
No browsing
3 drops during 1.50 minute
Then change to full screen and no browsing
No drop
CPU0 40 to 58 % - Kodi 47 %
http://xbmclogs.com/pat9jzrop

Play with DVDPlayer, mode file
CPU0 98 to 100 % - Kodi 95 %
No browsing
Then change to full screen and no browsing
CPU0 40 to 52 % - Kodi 47 %
NO DROP even when change to full screen.
http://xbmclogs.com/p3qcea7zl

[Milhouse]

I can easily reproduce.

Cool.

@popcornmix, @millhouse: It works for you? > 96 khz flac or multi channel flac?

I'd tried to reproduce in the past and failed, but perhaps I didn't have the exact same setup.

HDMI, Optimized, 5.1 channel configuration.

Funny sidenote: Disabling CEC seems to make it work better :-)

I almost always disable CEC as a matter of course (Harmony IR remote).

[fritsch]

HDMI output -> 6 channels -> Optimized to AVR (no AC3 transcode (should not be available anyways with 6 channels)

[popcornmix]

@popcornmix, @millhouse: It works for you? > 96 khz flac or multi channel flac?

I have seen it, but it's complicated. I'm pretty sure it occurs in Kodi (rather than on GPU).
I have seen two similar failure modes. First is the audio sink underrunning.
Second is no sink underrun, but AE explicitly pushes silence.

I did spend some time with FernetMenta long ago producing logs, but we never got to the bottom of this second case.

The strange thing is sometimes, with no obvious change in settings, it will play the 6 channel/96kHz flac track repeatedly without any drops.
When in this state, I can do what I like in the gui and nothing seems to provoke a drop.
I then restart kodi and start seeing drops.

I added the GUI setting to change the latency of the sink, assuming this would help but it has no effect.
Sometimes it's happy with latency of 50ms. Sometimes it's unhappy with a latency of 300ms.
(When changing latency make sure sink is recreated, e.g. by switching to analogue and back to hdmi).

It doesn't seem to be CPU related as Pi1 and Pi2 behave pretty similarly, and Pi2 has very low CPU usage in this case (Pi1 naturally is pretty busy).
Disabling visualisation doesn't help.
I believe there is no issue when forcing omxplayer as the audio player (but you lose gapless and visualisations).

[fritsch]

What makes me wonder is, that when I do "resampling" on top to 48 khz, it works without issues.

Wondering if there are some constraints in AESink implementation that "fear to run" dry, based on the samplerate, e.g. 96 khz is a lot :-)

[popcornmix]

What makes me wonder is, that when I do "resampling" on top to 48 khz, it works without issues.

Wondering if there are some constraints in AESink implementation that "fear to run" dry, based on the samplerate, e.g. 96 khz is a lot :-)

Yes, obviously the buffer size going to sink is halved when resampling to 48kHz which might avoid a bug in that area.

[fritsch]

When reading the code, it seems the sink is optimized for 2 channels and 100 ms buffer, which would mean 50ms of audio. In case of 6 channel audio, we still also only have 2 OMX_BUFFERS but that would reduce the audio in buffer to 100/6 = 1/3 * 50 ~ 16 ms. That puts high load onto AE.

On other platforms we always try to have arround 200 ms in the buffer.

Did you try tuning those two values:

#define NUM_OMX_BUFFERS 2
#define AUDIO_PLAYBUFFER (0.1) // 100ms

Edit: This is what you did with above "latency" setting?

[popcornmix]

When reading the code, it seems the sink is optimized for 2 channels and 100 ms buffer, which would mean 50ms of audio. In case of 6 channel audio, we still also only have 2 OMX_BUFFERS but that would reduce the audio in buffer to 100/6 = 1/3 * 50 ~ 16 ms. That puts high load onto AE.

The 2 OMX_BUFFERS aren't related to 2 channels - it just means we can send a second to GPU before the first one has been consumed
(although currently we always block so the second buffer isn't used).
We can easily make these buffers larger, but I don't believe that helps.

The actual buffer size is here, and should scale with number of channels and samplerate.

These buffers are just used for sending data to the GPU. The actual GPU dma ring buffer is larger (about 300ms),
but we manage latency by blocking when latency exceeds the desired value.

I have tried making the GPU dma ring buffer 4 times the size, without any change in behaviour.

[popcornmix]

I've dug out the logging I was using previousoly with FernetMenta. See here.
The dropouts occur when the following message appears:

Code:

17:25:19 3379.672363 T:1971201104  NOTICE: CActiveAESink::StateMachine CSinkDataProtocol::TIMEOUT S_TOP_CONFIGURED_SILENCE

It occurs at line 17986 in this log: http://paste.ubuntu.com/10696247/

Note: I played the whole 11minute file without a dropout on the run before this, so the dropouts are certainly not inevitable.
Also with one run (before I had this logging) the dropout lasted for about a second, and I could see the visualisation stop animating (it still rotated, just the bars didn't bounce),
so it seems pretty clear to me that this is a kodi, not a firmware issue.

[fritsch]

Code:

SetSilenceTimer();
          if (!m_extSilenceTimer.IsTimePast())
          {
            m_state = S_TOP_CONFIGURED_SILENCE;
          }

We need to log the value SetSilenceTimer() is telling us. I see it only going into S_TOP_CONFIGURED_SILENCE in the above case, which als only outputs some silence, if:

Code:

case S_TOP_CONFIGURED_SILENCE:
      if (port == NULL) // timeout
      {
        switch (signal)
        {
        case CSinkControlProtocol::TIMEOUT:
          OutputSamples(&m_sampleOfSilence);
          if (m_extError)
          {
            m_sink->Deinitialize();
            delete m_sink;
            m_sink = NULL;
            m_state = S_TOP_CONFIGURED_SUSPEND;
          }
          else
            m_state = S_TOP_CONFIGURED_PLAY;
          m_extTimeout = 0;
          return;
        default:
          break;
        }
      }
      break;

Isn't there a transition missing to "something else", e.g. PLAY if we would not have received the TIMEOUT?

[fritsch]

Wait another idea: Can you change SetSilenceTimer() to always return infinite? So that we "never timeout"?