Uninterrupted Music Flow

[GoogleCodeExporter]

I'm sure that most of you are quite aware that Mobbler (in its current
state) doesn't like it when other applications are running (especially in
the foreground). Just try using Google Maps while you listen to Last.fm and
you'll know what I mean.

I did some research on this matter and I've found a solution. It's a bit
complex, in that it requires the writing of a real-time priority thread to
host the music streaming engine. Before I spent any time trying that I
attempted everything else I could think of, including setting highest
priorities of everything possible (including the Mobbler applet), but
nothing work.

I therefore spent a fair amount of time writing the classes needed to host
the engine in a real-time priority thread. I then tested it using my own
version of the code. The idea works LIKE A CHARM. I can do absolutely
anything while Mobbler plays in the background without even so much as a
hiccup from the sound. I can surf the web, play with Google Maps, and even
play graphics-intensive games.

I therefore propose that this enhancement be added to the official version
of Mobbler.

Original issue reported on code.google.com by pbextreme@gmail.com on 20 Dec 2008 at 6:13

[GoogleCodeExporter]

I was FAIRLY CERTAIN I'd used the most recent edition, but it never hurts to be 
ABSOLUTELY SURE. To that end I'll download the most recent version of the trunk 
and 
I'll compile it without making any modifications. If that seems stable I'll 
re-add 
the MUTEX and see what happens then. I'll report back once I've had a chance to 
do 
these tests.

Original comment by steve.j.punter@gmail.com on 4 Jan 2009 at 4:11

[GoogleCodeExporter]

What is re-adding the mutex going to achieve?

Original comment by eartle@gmail.com on 4 Jan 2009 at 4:25

[GoogleCodeExporter]

I'm still of the opinion that the MUTEX is IMPORTANT for safe access to the 
shared 
data and I got the impression that putting it back in created at least one of 
my 
problems.

I'd posted a second message last night to which you didn't comment on(and so 
maybe 
you didn't read it). In that message I told you that I was getting repeated 
examples 
of an issue you'd raised a little while ago in in which the next song wouldn't 
start, but would continue to buffer. I hadn't seen that prior to adding the 
MUTEX 
code, and although it might have been a coincidence, I want to be sure that 
putting 
the MUTEX protection back in doesn't BREAK anything.

Original comment by steve.j.punter@gmail.com on 4 Jan 2009 at 4:38

[GoogleCodeExporter]

I think the mutex is unnecessary, as I explained on the equaliser issue.  I also
don't think we should blindly add things to solve problems we don't understand 
or
perhaps don't exist.

Yes, I read your message and thought that it sounded exactly the same as the 
problem
that I've already fixed, which is why I asked if you are sure you are using the
latest version.

Original comment by eartle@gmail.com on 4 Jan 2009 at 4:50

[GoogleCodeExporter]

I have compiled and installed the MOST RECENT source code from the trunk and 
it's 
been good so far. This probably means that I WAS using an older copy of the 
source 
when I did my tests last night. I'll keep testing this version throughout the 
day 
and I'll report if I find any problems.

Original comment by steve.j.punter@gmail.com on 4 Jan 2009 at 5:51

[GoogleCodeExporter]

Cheers!

Did you get the problem with the current song ending 5 seconds too soon a lot?  
When
I had this problem it happened every time.

I have been using it all day today and no problems so far, so fingers crossed!

Original comment by eartle@gmail.com on 4 Jan 2009 at 6:04

[GoogleCodeExporter]

I've been playing Mobbler for about half-an-hour now and so far I've not 
experience 
any difficulties at all. No early ending to songs, no panics, and no tracks 
failing 
to start while they continue to buffer. So far it looks very solid. I'll keep 
listening to Mobbler throughout the day and I'll see if anything pops up after 
prolonged use.

Oops! I spoke too soon. As I typed the above paragraph the song that was 
playing (it 
was about halfway through) ended abruptly with the error:

Application Closed:
local-c8315be8
USER 44

This only took down the currently-playing track. The next one started a few 
seconds 
later (after it had buffered presumably) and the program continued to run. I 
cleared 
the error from the screen after I'd typed out its content and Mobbler seemed to 
be 
running just fine. It moved on to the next song with no complaints.

Original comment by steve.j.punter@gmail.com on 4 Jan 2009 at 6:15

[GoogleCodeExporter]

A second USER 44 just occurred right near the end of a song. It was so close to 
the 
end in fact that I didn't really notice anything wrong with the audio. The 
error 
popped up just before the next song began to play. Once again, clearing the 
error 
left Mobbler running just fine.

I'm now going to put the MUTEX protection in and see if this causes these USER 
44 
errors to go away. I'll let you know if it works.

Original comment by steve.j.punter@gmail.com on 4 Jan 2009 at 6:22

[GoogleCodeExporter]

I got a third USER 44 on the original code while I worked on adding the MUTEX 
back 
into the code. I've now done that and this version is working well, but of 
course 
it's too soon to know for sure if adding the MUTEX to protect the shared data 
will 
have any impact on the problem.

Of course, if I get even a single USER 44 while testing this version, it proves 
that 
the MUTEX made no difference. Proving the opposite is going to be difficult, 
but 
judging by the frequency I was getting the USER 44, I think a few solid hours 
of 
playing music with NO PANICS is a strong indication that it worked.

I'll let you know if I get any panics in this version with the MUTEX back in 
place. 
Otherwise, I'll you know how many hours straight I played Mobbler without a 
problem.

Original comment by steve.j.punter@gmail.com on 4 Jan 2009 at 6:53

[GoogleCodeExporter]

Okay, it took 2 hours to popup, but I got a USER 44 error on the newest version 
with 
the MUTEX added back. That conclusively proves that the MUTEX didn't help, but 
it 
still leaves us with the question of what caused it. At least in the current 
version 
it doesn't actually bring down the player, it just causes it to move on to the 
next 
track (since normally, with no extended panic errors turned on, there would be 
no 
error message). However, it might be leaving memory leaks when this occurs.

Original comment by steve.j.punter@gmail.com on 4 Jan 2009 at 8:39

[GoogleCodeExporter]

I still haven't experienced this myself.

I've looked over the code and have no idea what this could be.  User 44 is 
normally
caused by deleting something twice, but I can't see where that could be 
happening.

Original comment by eartle@gmail.com on 4 Jan 2009 at 11:22

[GoogleCodeExporter]

I agree. I did some research and the concensus appears to be that USER 44 
panics 
occur when an object is deleted a second time. There is nothing apparently 
wrong 
with the code, and the rarity of the event doesn't suggest that you've done 
anything 
fundamentally wrong.

However, I have a fair bit of know-how with multi-threaded applications and 
it's 
been my experience that when a problem pops up AT RANDOM and INFREQUENTLY that 
the 
cause is almost always one of concurrency. I'll look over the code with an eye 
to 
what things MIGHT be able to execute in an unexpected order, or code that might 
be 
pre-empted at an inopportune moment.

Original comment by steve.j.punter@gmail.com on 5 Jan 2009 at 1:14

[GoogleCodeExporter]

I am going to consider this a non-showstopping issue and proceed with the next
realease with or without a fix for it.  This is because I have not had this 
problem
and you (Steve) get this at quite a low frequency, but mainly because the 
symptom is
not disastrous for the normal user as the next track starts and Mobbler 
continues to
function.

I think we should open the USER 44 problem as a seperate issue and consider the 
audio
thread stuff done, and a fantastic contirbution from Steve!

Original comment by eartle@gmail.com on 5 Jan 2009 at 10:40

[GoogleCodeExporter]

I've created Issue 221 to cover the USER 44 and am marking this as fixed.

Original comment by eartle@gmail.com on 5 Jan 2009 at 2:05

• Changed state: Fixed