Strange silence during playback via cue

Bug #500061 reported by rfcmedia
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Won't Fix
Medium
RJ Skerry-Ryan

Bug Description

This happens intermittently on Mixxx 1.7.1 but I sometimes have silence when I cue a song.
I managed to capture it on video. The following Youtube video illustrates two issues.

1) When I click and hold cue, I get some sound, but then it drops out until some later point (which is around where I used to have my cue point), at which point sound comes back. You can tell when it drops out by watching the sound bars.

2) In the last few seconds of the video, I encountered what seems to be bug #225305, although I was not rapidly clicking by any means, as you can tell from the CUE button alternating between gray and blue. When I let go of the cue button, the waveform didn't shift back to its original position and stayed where it stopped.

http://www.youtube.com/watch?v=m8QbhNQ58nk

Thanks! (By the way, I've verified bug #2 on v1.7.2 as well, compiled from the bzr repo on Ubuntu 9.10, about an hour ago)

Revision history for this message
rfcmedia (rfcmedia) wrote :

Sorry, Please ignore the link to "bug number 2". It's referring to my second bullet point, which is bug #225305.

Revision history for this message
Albert Santoni (gamegod) wrote : Re: [Bug 500061] Re: Strange silence during playback via cue

Can you try compiling 1.8?

My guess here is that our Reader class that decodes the MP3 is waiting
for your hard disk to seek to the start of the song when you cue up
like that, and if your disk is too slow, Mixxx ends up playing
silence. In 1.8, we have a much improved Reader that caches snippets
of audio like the part in front of a cue point, which tries to buy
your hard disk time to catch up. I'd be curious to hear what happens
if you try the same test in 1.8....

Thanks,
Albert

On Thu, Dec 24, 2009 at 1:22 AM, rfcmedia <email address hidden> wrote:
> Sorry, Please ignore the link to "bug number 2".  It's referring to my
> second bullet point, which is bug #225305.
>
> --
> Strange silence during playback via cue
> https://bugs.launchpad.net/bugs/500061
> 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 :

How do I get Mixxx 1.8? bzr checkout lp:mixxx/1.8 tells me that there
is no default branch.

Thanks!

On 12/24/2009 09:04 AM, Albert Santoni wrote:
> Can you try compiling 1.8?
>
> My guess here is that our Reader class that decodes the MP3 is waiting
> for your hard disk to seek to the start of the song when you cue up
> like that, and if your disk is too slow, Mixxx ends up playing
> silence. In 1.8, we have a much improved Reader that caches snippets
> of audio like the part in front of a cue point, which tries to buy
> your hard disk time to catch up. I'd be curious to hear what happens
> if you try the same test in 1.8....
>
> Thanks,
> Albert
>
> On Thu, Dec 24, 2009 at 1:22 AM, rfcmedia <email address hidden> wrote:
>> Sorry, Please ignore the link to "bug number 2". It's referring to my
>> second bullet point, which is bug #225305.
>>
>> --
>> Strange silence during playback via cue
>> https://bugs.launchpad.net/bugs/500061
>> 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 :

Awesome. Haven't encountered the bug yet today. Been trying to break
it by clicking a lot but... so far it's stable. I've been trying both
the trunk and the features_sqlite branch but both are solid!

Although, I noticed that in both branches, if I try the collusion and
outline themes, the Cue button works like the play button. (music does
not stop on mouse-release) Is this by design?

Thanks!

On 12/24/2009 09:04 AM, Albert Santoni wrote:
> Can you try compiling 1.8?
>
> My guess here is that our Reader class that decodes the MP3 is waiting
> for your hard disk to seek to the start of the song when you cue up
> like that, and if your disk is too slow, Mixxx ends up playing
> silence. In 1.8, we have a much improved Reader that caches snippets
> of audio like the part in front of a cue point, which tries to buy
> your hard disk time to catch up. I'd be curious to hear what happens
> if you try the same test in 1.8....
>
> Thanks,
> Albert
>
> On Thu, Dec 24, 2009 at 1:22 AM, rfcmedia <email address hidden> wrote:
>> Sorry, Please ignore the link to "bug number 2". It's referring to my
>> second bullet point, which is bug #225305.
>>
>> --
>> Strange silence during playback via cue
>> https://bugs.launchpad.net/bugs/500061
>> 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 :

Just happened to capture it again, but this time on mixxx 1.8 from features_sqlite.
I can't reproduce it but it happened at the end of a song... I'll report back when I manage to reproduce it.

http://www.youtube.com/watch?v=JavTam3kHC8

RJ Skerry-Ryan (rryan)
Changed in mixxx:
milestone: none → 1.8.0
assignee: nobody → RJ Ryan (rryan)
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

I think that if this happened at the end of the song, it's probably a Reader deadlock or something, and not the same bug that affects 1.7.2

RJ Skerry-Ryan (rryan)
Changed in mixxx:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Hm, we were never able to reproduce it even though the video shows it. Marking triaged.

Changed in mixxx:
status: Confirmed → Invalid
status: Invalid → Won't Fix
status: Won't Fix → Triaged
RJ Skerry-Ryan (rryan)
Changed in mixxx:
status: Triaged → Won't Fix
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/5251

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.