Topic: AAC Playback Problem

[Tron04]

Hello,

I noticed that xmplay (current and "stuff" version)  does not correctly playback aac+ 64kbit streams without xmp-aac.dll.
Other bitrates play fine. Without the DLL, it will play the stream for exactly 5 seconds and then will freeze.
I tried several 64kbit streams from several stations and the behavior was consistent.
(Example: http://uk2-pn.mixstream.net:8414/ )

As mentioned a workaround is to use xmp-aac.dll which does not have this bug.
(My System: Windows 10 Pro 1809 64bit)
Is it possible to fix this?

[sveakul]

I tried the link you supplied with Windows 7 SP1 32-bit and the latest XMPlay:

With xmp-aac.dll:  plays fine, as you described

With xmp-aac.dll renamed/removed (using Microsoft AAC):  plays fine

As above, but with priority given to LAV Filters AAC vs. Microsoft AAC:  plays fine

So not sure why you should have an issue with it, however, could be Windows 10 update related.  The bitrate really shouldn't make any difference, only the sample rate (the Windows AAC codec doesn't support AAC sample rates over 48kHz), but the latter isn't relevant in this case.

Seems to me keeping xmp-aac.dll in place is an easy workaround.

[Tron04]

As strange as it sounds, the error is not there when trying a 32kbit or 128kbit aac+ stream. But for 64kbit aac+ I have consistent crashes/freezes of xmplay (not using xmp-aac.dll).

[Ian @ un4seen]

I noticed that xmplay (current and "stuff" version)  does not correctly playback aac+ 64kbit streams without xmp-aac.dll.
Other bitrates play fine. Without the DLL, it will play the stream for exactly 5 seconds and then will freeze.
I tried several 64kbit streams from several stations and the behavior was consistent.
(Example: http://uk2-pn.mixstream.net:8414/ )

That stream appears to be down currently (I get an "ICY 401 Service Unavailable" message), so I'm unable to try reproducing the problem with it. Do you have another affected stream URL to try?

[Tron04]

Please try with this alternative URL (also 64bit aac+ stream): http://somafm.com/deepspaceone64.pls

[Ian @ un4seen]

Oh yes, I am able to reproduce the problem with that URL on Win10. It's a download buffering issue when using a Media Foundation codec. Here's an update that should fix it:

   www.un4seen.com/stuff/xmplay.exe

Let me know if you still see the problem happen with that.

[Tron04]

Only did a quick test, but it played more than 5 seconds :-)
Seems to be fixed! Thanks so much!

[sveakul]

Great job Ian!  I'm still confused though as what 64kbs has to do with it when the OP said other rates had no issue??  Must be Windows 10-specific, as it doesn't happen on my Windows 7 SP1 as I mentioned earlier.

[Ian @ un4seen]

I wasn't able to reproduce the problem on Win7 either. It looks like Media Foundation has a bit different file reading/buffering on Win7 and Win10. I think it was just coincidence that the problem appeared to only happen with 64kb/s AAC streams (the bitrate probably affects the buffering).

[sveakul]

Thanks Ian, interesting.

[tniemi]

Let me know if you still see the problem happen with that.

Problem fixed in Windows 10 Pro 10.0.17763.0

Edited:
It stuck once again when I switched from dock (ethernet) to wlan.

... but my XMPlay start shortcut is pointing to a PowerShell script:

Code: [Select]

# XMPlay.ps1
Set-Location (Split-Path $MyInvocation.MyCommand.Path)
do {
    tskill.exe "xmplay" > $NULL
} while (-not $LASTEXITCODE)
./XMPlay.exe
so one click, and the player is re-started.

(For the first time in 7 years I am being forced to use Windows for my work. It has been a bit painful, but one of the positive things is that I can use XMPlay again!)

[Ian @ un4seen]

Are you already using the latest XMPlay "stuff" update? If not, please give that a try and see if you still get the problem:

   www.un4seen.com/stuff/xmplay.exe

If you do still get the problem with that, also try with the XMPlay AAC plugin installed for comparison (to confirm whether the problem is related to the Media Foundation stuff).

PS welcome back