waveform becomes irresponsive in r2241 of trunk

Bug #503646 reported by rfcmedia
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Invalid
Undecided
Unassigned

Bug Description

Currently I cannot reproduce this, but while trying to jog-wheel waveform #1, the waveform completely stopped working.
The rest of the GUI is responsive though. At this point mixxx is using 39% CPU. After a bit more clicking around the entire GUI froze. Maybe the waveform thread ran away?

Unresponsive waveform shown here: http://www.youtube.com/watch?v=LL18Ep05fjw

[terminal]
Debug: [AnalyserQueue 1]: AnalyserBPM BPM detection successful for "01-basshunter-vi_sitter_i_ventrilo_och_spelar_dota.mp3"
Debug: [AnalyserQueue 1]: AnalyserBPM BPM is 139.865 (raw: 139.865 )
Debug: []: Couldn't get chunk 809 in read()
Debug: []: Couldn't get chunk 809 in read()
Debug: []: Couldn't get chunk 809 in read()
Debug: [Main]: TrackDAO::getTrack QThread(0x8ef9b98, name = "Main") "qt_sql_default_connection"
Debug: [Main]: TrackInfoObject: emitting bpmUpdated signal!
Debug: [Main]: setCuePoints 0
Debug: [Main]: TrackDAO::updateTrackInDatabase QThread(0x8ef9b98, name = "Main") "qt_sql_default_connection"
Debug: [Main]: Updating track "Basshunter, Now You're Gone" in database...
Debug: [Main]: TrackInfoObject: emitting bpmUpdated signal!
Debug: [Main]: CueControl::loadTrack
Debug: [AnalyserQueue 1]: AnalyserWaveform: f 44100 samplesPerDownsample: 110 downsamples 162432 from 17867520
Debug: [Main]: Received waveform from track
Debug: [AnalyserQueue 1]: AnalyserWavesummary generation successful for "Heartbreaker.mp3"
Debug: [AnalyserQueue 1]: AnalyserWaveform :: Waveform downsampling finished.
Debug: [AnalyserQueue 1]: AnalyserWaveform :: Generation took 2.33 seconds
Debug: [Main]: Destroying MixxxApp
Debug: [Main]: save config, 0
Debug: [Main]: close soundmanager 1
Killed
[/terminal]

Revision history for this message
Albert Santoni (gamegod) wrote : Re: [Bug 503646] [NEW] waveform becomes irresponsive in r2241 of trunk

Looks like the Readers either both froze (I've never seen both go like
that), or the PortAudio callback died.

Can you confirm that you're using the version of PortAudio that we
recommend on the Mixxx site?

If you're not, go to http://www.mixxx.org/download.php , click Ubuntu,
and then it'll tell you to install a specific older version of
PortAudio. We were seeing a problem that looked just like this, and we
were able to track it down to a bad PortAudio version...

Thanks,
Albert

On Tue, Jan 5, 2010 at 5:59 PM, rfcmedia <email address hidden> wrote:
> Public bug reported:
>
> Currently I cannot reproduce this, but while trying to jog-wheel waveform #1, the waveform completely stopped working.
> The rest of the GUI is responsive though.  At this point mixxx is using 39% CPU.  After a bit more clicking around the entire GUI froze.  Maybe the waveform thread ran away?
>
> Unresponsive waveform shown here:
> http://www.youtube.com/watch?v=LL18Ep05fjw
>
>
> [terminal]
> Debug: [AnalyserQueue 1]: AnalyserBPM BPM detection successful for "01-basshunter-vi_sitter_i_ventrilo_och_spelar_dota.mp3"
> Debug: [AnalyserQueue 1]: AnalyserBPM BPM is  139.865  (raw:  139.865 )
> Debug: []: Couldn't get chunk  809  in read()
> Debug: []: Couldn't get chunk  809  in read()
> Debug: []: Couldn't get chunk  809  in read()
> Debug: [Main]: TrackDAO::getTrack QThread(0x8ef9b98, name = "Main") "qt_sql_default_connection"
> Debug: [Main]: TrackInfoObject: emitting bpmUpdated signal!
> Debug: [Main]: setCuePoints 0
> Debug: [Main]: TrackDAO::updateTrackInDatabase QThread(0x8ef9b98, name = "Main") "qt_sql_default_connection"
> Debug: [Main]: Updating track "Basshunter, Now You're Gone" in database...
> Debug: [Main]: TrackInfoObject: emitting bpmUpdated signal!
> Debug: [Main]: CueControl::loadTrack
> Debug: [AnalyserQueue 1]: AnalyserWaveform: f  44100  samplesPerDownsample:  110  downsamples  162432  from  17867520
> Debug: [Main]: Received waveform from track
> Debug: [AnalyserQueue 1]: AnalyserWavesummary generation successful for  "Heartbreaker.mp3"
> Debug: [AnalyserQueue 1]: AnalyserWaveform :: Waveform downsampling finished.
> Debug: [AnalyserQueue 1]: AnalyserWaveform :: Generation took  2.33  seconds
> Debug: [Main]: Destroying MixxxApp
> Debug: [Main]: save config,  0
> Debug: [Main]: close soundmanager 1
> Killed
> [/terminal]
>
> ** Affects: mixxx
>     Importance: Undecided
>         Status: New
>
> --
> waveform becomes irresponsive in r2241 of trunk
> https://bugs.launchpad.net/bugs/503646
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

Revision history for this message
jus (jus) wrote :

MacOS 10.5.8 / Mixxx r2250

Same here, not exactly as rfcmedia but because it occurs only on channel 1 it may related.

Every song i play to its very end the waveform completely stopped working. No rewind ,cue , loop - nothing.
Channel 1 comes back to life when loading a new track from the library.
http://dl.dropbox.com/u/3077984/Mixxxr2250_os10.5.8_hang_waveform_ch1.mov

MacOS 10.6.2 / Mixxx r2250
No such problem

Revision history for this message
Albert Santoni (gamegod) wrote : Re: [Bug 503646] Re: waveform becomes irresponsive in r2241 of trunk

jus: Your hang is a Reader deadlock because you're using NEXT mode. We
should probably file that as a separate bug (I've been able to
reproduce it before).

Thanks!
Albert

On Thu, Jan 7, 2010 at 5:37 AM, jus <email address hidden> wrote:
> MacOS 10.5.8 / Mixxx r2250
>
> Same here, not exactly as rfcmedia but because it occurs only on channel
> 1 it may related.
>
> Every song i play to its very end the waveform completely stopped working. No rewind ,cue , loop - nothing.
> Channel 1 comes back to life when loading a new track from the library.
> http://dl.dropbox.com/u/3077984/Mixxxr2250_os10.5.8_hang_waveform_ch1.mov
>
> MacOS 10.6.2 / Mixxx r2250
> No such problem
>
>
> ** Attachment added: "Mixxxr2250_os10.5.8_hang_waveform_ch1.txt"
>   http://launchpadlibrarian.net/37542458/Mixxxr2250_os10.5.8_hang_waveform_ch1.txt
>
> --
> waveform becomes irresponsive in r2241 of trunk
> https://bugs.launchpad.net/bugs/503646
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

Revision history for this message
rfcmedia (rfcmedia) wrote :

Hm. It certainly could be the PortAudio -- I'm using the 19+2009 version on Ubuntu Karmic...
However, I cannot use the older version because it doesn't support PulseAudio properly! Nor does it even detect all the Alsa PCM devices properly.
Of course I understand you can't do much about that... I guess I'll try a nightly build of PortAudio later.

Are there any workarounds?

Revision history for this message
Albert Santoni (gamegod) wrote :

Well, the workaround is to try use that older version. :)

One other thing worth trying is setting this environment variable in
your terminal before launching Mixxx:

    export PA_ALSA_PLUGHW=1

See if that helps,
Albert

On Thu, Jan 7, 2010 at 11:43 AM, rfcmedia <email address hidden> wrote:
> Hm.  It certainly could be the PortAudio -- I'm using the 19+2009 version on Ubuntu Karmic...
> However, I cannot use the older version because it doesn't support PulseAudio properly!  Nor does it even detect all the Alsa PCM devices properly.
> Of course I understand you can't do much about that... I guess I'll try a nightly build of PortAudio later.
>
> Are there any workarounds?
>
> --
> waveform becomes irresponsive in r2241 of trunk
> https://bugs.launchpad.net/bugs/503646
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

Revision history for this message
rfcmedia (rfcmedia) wrote :

Heh, the older version won't let me use the "default" sound device which gets tied to PulseAudio.
So I tried the nightly build from Jan 8 2010 of PortAudio and encountered the same symptom.

So I searched around, downloaded PortAudio stable 20071207 version from their website, then applied Kevin Kofler's pulseaudio patch found at http://music.columbia.edu/pipermail/portaudio/attachments/20081109/0bac4272/attachment.patch followed by a compile and some nice LD_LIBRARY_PATHing.

So far it's working... I'll report back with any more problems.

I suspect Albert is correct in blaming PortAudio.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

rfcmedia: Have you run into the issue again after changing your portaudio version?

Thanks,
RJ

Changed in mixxx:
milestone: none → 1.8.0
Revision history for this message
rfcmedia (rfcmedia) wrote :

After switching to the portaudio with patch as detailed above I have not had any crashes.
However, I have only used Mixxx for ~1 hr since I last updated this bug. So my answer would be, I'm not sure.
Thanks!

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Tentatively marking Invalid...

Changed in mixxx:
status: New → Invalid
Revision history for this message
Swiftb0y (swiftb0y) wrote :

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

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.