tuni.ac

So I thought I'd make another attempt at implementing some new things into Tuniac.

Getting Tuniac built according to the instructions wasn't any big issue, and it seems to run well for the most part. However, in all my builds it never advances to the next song after one has been played. Not in 32bit builds and not in 64bit builds. Not in release nor debug.
I tried to build an x64 release and just use my compiled exe with the plugins and other files of the official release, and it doesn't work there either.
No "soft pause" or "automatically stop after each song" are enabled.

It does work if I enable cross fade though.

But it looks like there's some kind of issue detecting the end of a file?

When it reaches the end of a song, sometimes the seekbar advances a bit too far.

Whenever it's in this state, if I seek back to the middle and try to pause / unpause, nothing happens.

Does anyone have any idea what could be wrong here? Or how I could debug this?

(EDIT: First post of 2022, yay)

BTW, this is what I'm playing around with this time around: https://github.com/Harteex/Tuniac/commits/jellyfin

I just checked the guide and it said to use vs 2016, I actually now build with VS Community 2019 and the project files were updated to 2019 some time ago.

The settings and media library should be shared with things I have built.
Eg you have my build in c:\program files\tuniac and yours in c:\testtuniac the settings and db would be shared.
If you run then one at a time mine works and then yours doesn't?

Does a build from your machine work if you build without your code changes?
Does the problem relate to playing Jellyfin files or local files?
The problem sounds like Tuniac audio engine doesn't correctly send the required message to the main Tuniac window.
So the audio engine has shut down the stream but the main window thinks it is still playing?

I would add the play state to the window title:
options -> preferences -> formatting -> window title -> Pick the second "@!: @T - @A [Tuniac]"
Observe the window title for if it says playing, paused etc when it goes past the end of the file.

And then to debug the best is to brute force with breakpoints, stepping and continue (to the next breakpoint).
The breakpoints proves you are executing that section of code at that time.
It is possible to find that tuniac tried to access something that wasn't available and you will find things just stop executing.
Your job is to find if that is occurring and what the "something" is via brute force breakpoints showing that execution never gets past line x.
While paused in breakpoints you can check out the state of current variables which can also assist.

I would run debug build and put break points in AudioStream.cpp GetBuffer() after m_Packetizer.IsFinished()
That is supposed to get to tuniacApp.CoreAudioMessage(NOTIFY_COREAUDIO_PLAYBACKFINISHED, NULL);
That is a message that it sends to the main window which gets you to TuniacApp.cpp WM_APP and find: case NOTIFY_COREAUDIO_PLAYBACKFINISHED
Set more breakpoints inside the tuniacapp playbackfinished to prove you go to there and then a break point near PlayEntry().
Set more and more breakpoints to prove what does work and where it fails

We need to prove
1)the audio engine knows it ran out of file
2)audio engine sent a message to the main window
3)that message was received
4)the message successfully processed

Let me know if you need more info.

Thanks for your response

Brett wrote: Mon Jan 03, 2022 11:48 am I just checked the guide and it said to use vs 2016, I actually now build with VS Community 2019 and the project files were updated to 2019 some time ago.

Yep, I'm using VS 2019. Figured that out from the scripts, and also there is no VS 2016.

Brett wrote: Mon Jan 03, 2022 11:48 am The settings and media library should be shared with things I have built.
Eg you have my build in c:\program files\tuniac and yours in c:\testtuniac the settings and db would be shared.
If you run then one at a time mine works and then yours doesn't?

Correct, they are shared. I run one at a time and yours work but mine doesn't.

Brett wrote: Mon Jan 03, 2022 11:48 am Does a build from your machine work if you build without your code changes?
Does the problem relate to playing Jellyfin files or local files?
The problem sounds like Tuniac audio engine doesn't correctly send the required message to the main Tuniac window.
So the audio engine has shut down the stream but the main window thinks it is still playing?

I've tried without any code changes and it still doesn't work. I've tried both local files and streams, nothing works.

Brett wrote: Mon Jan 03, 2022 11:48 am I would add the play state to the window title:
options -> preferences -> formatting -> window title -> Pick the second "@!: @T - @A [Tuniac]"
Observe the window title for if it says playing, paused etc when it goes past the end of the file.

And then to debug the best is to brute force with breakpoints, stepping and continue (to the next breakpoint).
The breakpoints proves you are executing that section of code at that time.
It is possible to find that tuniac tried to access something that wasn't available and you will find things just stop executing.
Your job is to find if that is occurring and what the "something" is via brute force breakpoints showing that execution never gets past line x.
While paused in breakpoints you can check out the state of current variables which can also assist.

I would run debug build and put break points in AudioStream.cpp GetBuffer() after m_Packetizer.IsFinished()
That is supposed to get to tuniacApp.CoreAudioMessage(NOTIFY_COREAUDIO_PLAYBACKFINISHED, NULL);
That is a message that it sends to the main window which gets you to TuniacApp.cpp WM_APP and find: case NOTIFY_COREAUDIO_PLAYBACKFINISHED
Set more breakpoints inside the tuniacapp playbackfinished to prove you go to there and then a break point near PlayEntry().
Set more and more breakpoints to prove what does work and where it fails

We need to prove
1)the audio engine knows it ran out of file
2)audio engine sent a message to the main window
3)that message was received
4)the message successfully processed

Let me know if you need more info.

breakpoints.JPG

The titlebar keeps saying "Playing" after the track has ended.
The packetizer is finished, but the stream isn't (m_Output->StreamFinished()).
So there is no message in TuniacApp / WM_APP obviously as it's never sent.

I made a screen recording as well in case that makes it easier to see
https://youtu.be/TKouYVJ03jE

It's a local file being played.

EDIT:
So, I assume OnStreamEnd is not called from Xaudio2 correctly. Breakpointing in AudioOutput.h in the OnStreamEnd callback, the breakpoint is never hit.
The documentation for OnStreamEnd says "OnStreamEnd is triggered when XAudio2 processes an XAUDIO2_BUFFER with the XAUDIO2_END_OF_STREAM flag set."
Looking at row 174 in AudioOutput.cpp, it does set the flag:

I ran out of time for doing edits, so here's a reply.
It turns out SubmitSourceBuffer returns XAUDIO2_E_INVALID_CALL.
The description for that is:
"Returned by XAudio2 for certain API usage errors (invalid calls and so on) that are hard to avoid completely and should be handled by a title at runtime. (API usage errors that are completely avoidable, such as invalid parameters, cause an ASSERT in debug builds and undefined behavior in retail builds, so no error code is defined for them.)"

If I change buf.AudioBytes to a non-zero value, it works.
I'm using the XAudio2 from the Windows SDK, which should be 2.9. Maybe you use the one in the DirectX SDK? (which might be 2.7 if I understood this correctly). And the behaviour has changed between versions.

Yea Tuniac is meant to use Xaudio 2.7 from Directx June 2010.
My guide mentions the DX SDK June 2010 regarding the svp renderer but it certainly is being used by Tuniac for xaudio also.

So either install the old dx sdk or do some good testing to prove you have 2.9 working correctly and we can move Tuniac to 2.9


Edit: oh 2.9 doesn't support Vista which Tuniac still does.

I just installed the nuget for the redistributable xaudio 2.9.
For that nuget the 1.2.8 seemed to crash vs 2019 during install but I could install 1.2.7 and upgrade to 1.2.8.
I find I need >8 bytes for buf.AudioBytes for OnStreamEnd() to trigger.

Each xaudio2_9redist.dll takes up about 250kb in the installer. 2x ~250kb for 32+64bit installer.

Obviously xaudio 2.9 would bump the OS requirements from Vista to 7 SP1


Edit:
Build 220104 has XAudio 2.9
http://wasteofcash.com/Tuniac/

Brett wrote: Mon Jan 03, 2022 11:47 pm So either install the old dx sdk or do some good testing to prove you have 2.9 working correctly and we can move Tuniac to 2.9

Edit: oh 2.9 doesn't support Vista which Tuniac still does.

I suppose both could be supported without much trouble.
What about WinXP btw, wasn't that still supported as well?

Brett wrote: Tue Jan 04, 2022 8:39 am I just installed the nuget for the redistributable xaudio 2.9.
For that nuget the 1.2.8 seemed to crash vs 2019 during install but I could install 1.2.7 and upgrade to 1.2.8.
I find I need >8 bytes for buf.AudioBytes for OnStreamEnd() to trigger.

Each xaudio2_9redist.dll takes up about 250kb in the installer. 2x ~250kb for 32+64bit installer.

Obviously xaudio 2.9 would bump the OS requirements from Vista to 7 SP1


Edit:
Build 220104 has XAudio 2.9
http://wasteofcash.com/Tuniac/

Simply using this small buffer (instead of a completely empty one) will probably introduce a short delay between songs, but it may not be noticable at all though.
The best would be to identify the last real buffer and set the XAUDIO2_END_OF_STREAM flag there.
I attempted a solution for this, with sending a small buffer as a fallback, in case there is some situation where the buffer would end unexpectedly, due to some kind of seeking or whatever.

What do you think of this?
https://github.com/Harteex/Tuniac/commi ... 60471fa80b
Might be a bit overengineered though.

Edit:
I might have asked this at some point before, but what do you think about migrating the repo to Github? It's easier to collaborate there with pull requests. Also the builtin Git support in VS is very nice. You can import the SVN repo directly on the Github site, including matching authors to Github profiles.
If not, that's fine
If you like the above solution, I can commit it with SVN access, or I can generate a patch for you.

Ok I have uploaded to github:
https://github.com/twistedddx/Tuniac

Immediately I had managed to confuse github about which email account I wanted to push from so now a second account in the commit log but I can live with that

I also updated to vs 2022 including the lib building scripts, updated the setup to remove directx stuff, added xaudio 2.9 redist nuget and added missing optimfrog files. Unfortunately for you I did 90% of that in the svn so not sure how easy it is to merge for you now.
Going forwards everything will be in github.

Awesome

No problem about the merge, I saved my commits as patches and applied them in my new branch.

I'm starting out with a few smaller PRs with things I find along the way towards greater things.