audio latecy usage meter at 100% when track loaded + paused

[mixxxbot]

Reported by: sblaisot Date: 2015-09-12T10:16:21Z Status: Fix Released Importance: Critical Launchpad Issue: lp1495047 Attachments: [equalizer preferences](https://bugs.launchpad.net/bugs/1495047/+attachment/4509841/+files/equalizer preferences), mixxx.log

---

today I faced something really strange.

64bits 1.12 git5545 on win10 64bits

track was playing in deck 1. deck 2-4 were empty. buffer fill indicator was low.

loaded a track in deck 2, on played it. buffer indicator still low.

as soon as I paused deck 1, the buffer indicator jumped very high in the red, stayed there and sound (from track in deck 2) began to be crackling.

so I played a bit with this situation (glad it was not during a gig), and found that the high buffer only happens when there is a paused track loaded in deck 1. if you eject track, the buffer indicator becomes low. if you play the track, no problem. if you load a new track (paused at load), it begins to fill buffer and produce bad sound. so if a track is loaded and paused in deck 1, buffer fill indicator jumps into red and sound begin to be so bad that it is unusable.

I did not see the same for other decks.

If I restart mixxx, everything works fine for some time.

I thing we face a race condition when, sometimes, maybe in particular conditions, you pause a track.

I'm not sure I will be able to reproduce it easily.

What can I check/do to gather more information ?

[mixxxbot]

Commented by: sblaisot Date: 2015-11-01T18:12:53Z

---

made some more tests :

1) I have hundreds lines of "flush to zero mode not working" so it seams that the flag is reset all the time. it doesn't seems to be correlated with number of core although I can't garantee that windows save/restore fp flags on thread switch

2) I verified the flags at the end of the callbackProcessClkRef() function, they are still set, so there is no code inside that function that disables the flags.

[mixxxbot]

Commented by: ywwg Date: 2015-11-01T18:13:25Z

---

Can you build from source? The git bisect command can help narrow down the issue, as long as you can find a revision without the bug.

[mixxxbot]

Commented by: daschuer Date: 2015-11-01T18:42:26Z

---

I can't garantee that windows save/restore fp flags on thread switch

Since I do not see the issue, it can't be a windows issue nor a Mixxx issue.

Maybe it's a diver issue. It mightbe possible, that the your diever whants to set the flag as well, but fails to restor the original state and instead it goes back to default, which is unset.

Which Sound API do you use?

[mixxxbot]

Commented by: daschuer Date: 2015-11-01T18:45:44Z

---

IMHO seaching the faulty commit does not lead to a solution of the issue. You will probably find the commits where we hav introduced fidlib as IIF Filter generator. But that does not matter, since we need FTZ for all effect code.

I am considering to set FAZ on every callback as a band aid. I will have a look how expensive surch a set is.

[mixxxbot]

Commented by: daschuer Date: 2015-11-01T18:52:19Z

---

Got it! I can reproduce you issue using Direct Sound API.

[mixxxbot]

Commented by: ywwg Date: 2015-11-01T19:00:14Z

---

If we have to add a per-callback workaround, we should make sure it's as narrowly targeted as possible.

[mixxxbot]

Commented by: sblaisot Date: 2015-11-01T19:22:51Z

---

You're right, I'm using directsound API.

I have choosen this one because I don't have any device in ASIO API (I didn't install IASO drivers nor ASIO4ALL :( )

I will see if I can find ASIO driver for my intagrated soundcard I'm using to test in my desktop PC.

I have ASIO4ALL installed on my laptop, but I forgot I had once to change sound API in Mixxx to fallback to directsound and forgot to switch back to ASIO :(

[mixxxbot]

Commented by: sblaisot Date: 2015-11-01T19:42:30Z

---

Tried with ASIO4ALL => no problem.

so the problem is definitively around DirectSound API

[mixxxbot]

Commented by: daschuer Date: 2015-11-01T20:01:02Z

---

The time for setting and querying the flags is not measurable compared to the jitter of the timer call. I assume that it is just as fast as setting any other CPU registers. The manual denormals assertion takes much longer.

So it should be no harm to regularly set the bits.

We may guard it by WINDOWS but we have no overview which API driver combination is effected on which target. So I prefer to just set the bits always.

[mixxxbot]

Commented by: daschuer Date: 2015-11-01T20:18:27Z

---

Implemented here, please check: https://github.com/mixxxdj/mixxx/commit/c53fc66f679a9b3a0a784650edd5e3d0f03fd62e

[mixxxbot]

Commented by: daschuer Date: 2015-11-02T06:42:42Z

---

Cool!

[mixxxbot]

Issue closed with status Fix Released.