Momentary freeze (audio glitch/silence) during disk IO

[Sean M. Pappalardo]

When playing a newly-analyzed track, Mixxx freezes for a split second when the computer reads from disk (glitches happen while the external drive shows activity). Noticed it on FLAC files.

Subsequent loads of an analyzed track don't show this behavior.

Happens on Athlon64 2GHz, 1.25GB RAM, Debian squeeze AMD64
Hard disk is external mirrored (hardware RAID,) XFS file system, connected via Firewire 400 (through a PCMCIA card with TI chipset)

[Sean M. Pappalardo (pegasus-renegadetech)]

I uncommented line 326 (a qDebug) in cachingreader.cpp per RJ's direction and found that this is indeed the problem: CachingReader::read() blocks. I even see the gitch/freeze/momentary silence at 170ms latency, so something's not right with the threading.

[absolut_beginner (onlyanorthernsong)]

Same Problem for me:

My hardware:
Notebook:
- Chiligreen Platin SE Notbook with Intel Celeron processor M743 (ULV 1.3 GHz, 1MB L2 Cache, 800 MHz), 3GB DDR RAM, Toshiba 500GB, Intel Graphics Media Accelerator (GMA) 4500M, 3x USB 2.0. Audio Interface is a Realtek HD Audio (lspci says: AUDIO DEVICE: Intel Corp. 82801I (ICH Family) HD Audio Controller (rev03))

DJ Console
- Hercules DJ Console RMX

External hard disc 2.5", USB 2.0, 500GB

My operating system: Dual-Boot Windows 7 & Ubuntu 10.10

- with Kernel 2.6.35-22-generic:
whenever I play a (new) track from a external USB-Disc with MIXXX i get a audio glitch/pop during the whole song. These pops & glitches also appear when I load a second track to a deck. So glitches and pops while normal playing on a deck AND during loading a second track to a deck while a song is playing on the other deck.

- with Kernel 2.6.36-rc7-maveric
improvements but still pops and audio glitches when loading a new track an Deck Y while a song is actually playing on Deck X. But less pops and glitches while playing only one song on one deck.

MIXXX under windows works fine on the same notebook - no glitches or pops during playing or loading of a song to a deck.

[absolut_beginner (onlyanorthernsong)]

Sorry, i forgot: I'm Using MiXXX 1.8.1 (haven't found a opportunity to edit my previous post)

[Daniel James (daniel-64studio)]

Hi Sean, I can reproduce this with FLACs (but not WAVs) after building Mixxx 1.8.0 from source, but can't reproduce when running 1.8.1 using the developer PPA packages for lucid. See my comment #48 here:

https://bugs.launchpad.net/mixxx/+bug/529614/comments/48

Can you reproduce this with any file format other than FLAC?

Cheers!

Daniel

[Daniel James (daniel-64studio)]

Update: I duplicated my setup on a less powerful laptop (Turion 1.6 GHz vs. dual Opteron 240 1.4 GHz in the earlier test) and I can get the glitch even when using the PPA packages of Mixxx. So I think this is performance related. With the PPA packages on both amd64 systems I'm seeing CPU loads from Mixxx in the 90% range, so perhaps 1.8.x is significantly more CPU hungry than earlier series. I will try optimized builds with the debug messages switched off.

[Sean M. Pappalardo (pegasus-renegadetech)]

Daniel: would you mind testing the features_flac code branch? https://code.launchpad.net/~mixxxdevelopers/mixxx/features_flac
That one uses libFLAC instead of libsndfile to read FLAC files and I wonder if it has better I/O handling since this problem seems only to affect FLAC files. (Note that that branch will alter your library format so please back up your 1.8 library before running it.)

[Daniel James (daniel-64studio)]

Hi Sean, I have tested the 1.8.2 release on Lucid, does this use libFLAC? Running 1.8.2 tThe glitch on track load hasn't gone, and I can hear it when loading MP3's as well. So I think this is a performance/CPU load issue which will affect all older machines, rather than a problem with FLAC support as such.

[RJ Skerry-Ryan (rryan)]

Hi Daniel,

The 1.9.0 beta has libFLAC. 1.8.2 does not. You may well be right that it
is a general performance problem. However, it'd be great to have that extra
datapoint of whether or not it was a FLAC issue. If you get a chance could
you please try out the 1.9.0 beta?

Cheers,
RJ

On Fri, Dec 10, 2010 at 5:11 PM, Daniel James <[e-mail]> wrote:

> Hi Sean, I have tested the 1.8.2 release on Lucid, does this use
> libFLAC? Running 1.8.2 tThe glitch on track load hasn't gone, and I can
> hear it when loading MP3's as well. So I think this is a performance/CPU
> load issue which will affect all older machines, rather than a problem
> with FLAC support as such.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/666052
>
> Title:
> Momentary freeze (audio glitch/silence) during disk IO
>

[Daniel James (daniel-64studio)]

Hi RJ,

I have backported 1.8.2 amd64 to Debian squeeze with interesting results. Running on a squeeze system with an rt kernel and the rtirq script, I can load flacs on the exact same laptop without glitches. CPU load is very high, 90% + with the waveforms displayed, but only around 10% with the waveforms switched off. So I think the performance problems on older Linux laptops are probably openGL related, if there is no hardware acceleration available. Plus using an rt kernel and rtirq can solve glitch problems even when CPU load is really high.

I'll try building 1.9.0-beta1 on Lucid next.

[Owen Williams (ywwg)]

Is this bug fixed with the new mmap code? It's been a long time since I've heard stuttering on track loads.

[William Good (bkgood)]

The underlying problem is still there in that one long IO read can
still cause the total output to glitch. I think it has been fixed for
most cases, though, through a handful of optimizations for people with
sufficiently fast computers.

On Mon, Aug 1, 2011 at 12:45 PM, Owen Williams <email address hidden> wrote:
> Is this bug fixed with the new mmap code?  It's been a long time since
> I've heard stuttering on track loads.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/666052
>
> Title:
>  Momentary freeze (audio glitch/silence) during disk IO
>
> Status in Mixxx:
>  Confirmed
> Status in Mixxx 1.8 series:
>  Won't Fix
>
> Bug description:
>  When playing a newly-analyzed track, Mixxx freezes for a split second
>  when the computer reads from disk (glitches happen while the external
>  drive shows activity). Noticed it on FLAC files.
>
>  Subsequent loads of an analyzed track don't show this behavior.
>
>  Happens on Athlon64 2GHz, 1.25GB RAM, Debian squeeze AMD64
>  Hard disk is external mirrored (hardware RAID,) XFS file system, connected via Firewire 400 (through a PCMCIA card with TI chipset)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/666052/+subscriptions
>

[Sean M. Pappalardo (pegasus-renegadetech)]

Well then we need to fix the underlying problem in order to close this. Who wants it?

[Geoff Oakham (g-launchpad-v)]

Maybe it would be worth using realtime priorities, and prioritizing the threads accordingly. (Ie, have all CPU and IO related to live playing music marked as "realtime", and the remaining (loading new media, analysis) as not.

I can empathise at how drastic a code change this probably is. On the plus side, it could make Mixxx's playback nearly bullet-proof.

[Owen Williams (ywwg)]

There is already a lot of realtime-enabled code in mixxx. This bug is going to be very hard to fix, involving some very noodly OS-specific testing and debugging.

One idea I had: when the user clicks to load a track, first precache several extra seconds of samples, if memory allows. Then when the track load happens, continuing playback will be a pure memory operation. This may cause a delay in the track load, but I don't think those need to be instantaneous.

But, there are also situations where there have been dropouts even when there shouldn't be. Like, qDebug() calls on linux were causing pops. That's what I mean about doing some low-level OS debugging.

[iltony (iltony)]

Is it an internal or an external drive? Are you using ext or ntfs, and if it's the latter, do you use a fuse or a kernel module? Did you enabled real time? And then: do you have an nvidia graphic card?
I'm asking you this things because, it's not always a mixxx problem when running in real time mode on linux: sometimes it's more something OS related. What you should get (what I get) is an interface freeze, but not a sound freeze, when loading a new sound.

[Geoff Oakham (g-launchpad-v)]

Owen: none of the threads were marked at "realtime" the last time I tried hard to troubleshoot/solve this problem with custom kernel and mixxx builds, even though I had limits setup properly. I don't understand why (but I haven't looked at the code either).

iltony: typically, I have an external USB2 drive with a fat32 (loaded kernel module). However, I believe I also tested playing songs directly from my ext4-formatted partition with the same results. I would be happy to try it again when I get home. (Side note: I have the same problem whether or not I use an external USB soundcard or the internal one. So I don't think the USB activity alone is causing the problem.)

I hope that helps. I'm happy to try dev/debug builds on my netbook.. just send me patches or whatnot.

[gontie (gbonaert)]

To be honest it is quiet a while i diden't faced the issue.

In my case it was a desktop and a internal disk.

The DPC latency checker is perfect so that is not issue.

> Date: Mon, 26 Sep 2011 19:25:28 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 666052] Re: Momentary freeze (audio glitch/silence) during disk IO
>
> Is it an internal or an external drive? Are you using ext or ntfs, and if it's the latter, do you use a fuse or a kernel module? Did you enabled real time? And then: do you have an nvidia graphic card?
> I'm asking you this things because, it's not always a mixxx problem when running in real time mode on linux: sometimes it's more something OS related. What you should get (what I get) is an interface freeze, but not a sound freeze, when loading a new sound.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (831412).
> https://bugs.launchpad.net/bugs/666052
>
> Title:
> Momentary freeze (audio glitch/silence) during disk IO
>
> Status in Mixxx:
> Confirmed
> Status in Mixxx 1.8 series:
> Won't Fix
> Status in Mixxx 1.9 series:
> Confirmed
>
> Bug description:
> When playing a newly-analyzed track, Mixxx freezes for a split second
> when the computer reads from disk (glitches happen while the external
> drive shows activity). Noticed it on FLAC files.
>
> Subsequent loads of an analyzed track don't show this behavior.
>
> Happens on Athlon64 2GHz, 1.25GB RAM, Debian squeeze AMD64
> Hard disk is external mirrored (hardware RAID,) XFS file system, connected via Firewire 400 (through a PCMCIA card with TI chipset)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/666052/+subscriptions

[RJ Skerry-Ryan (rryan)]

Neale Pickett dropped into IRC and had some positive news. He says that with 1.10 beta, his netbook is much better than in 1.9.0.

His hardware is an Atom N270 1.6GHz processor (Samsung NC10) on Arch Linux with ALSA and a $10 USB soundcard (SYBA SD-CM-UAUD) on top of his internal one. His hard-disk is not an SSD.

He reports that even with both decks, all 4 samplers, and microphone all active he rarely gets xruns at 5ms and almost never gets xruns at 10ms (I think he says he got one in his whole testing session). Even while doing non-mixing tasks like searching the library.

In 1.9.0 he says he got xruns periodically even at 21ms latency with only 2 decks playing.

Based on this, I think I'm willing to declare victory on this bug. To be sure, the engine still has problems (which we already have a plan for dealing with in later releases) that can lead to priority inversion, but we have made huge progress.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5608