PDA

View Full Version : Pausing when skipping Apple Lossless tracks



nuttyphilt
2007-08-14, 08:36
Hi,

My setup:

Dell Inspiron 700M laptop, the Slimserver is on this, connected wirelessly.
Maxtor Shared Storage NAS - this contains all my music, 75% of which is Apple Lossless.
Squeezebox 3, connected wirelessly.
Slimserver plugins: LastFM, AlienBBC, iTunes update, Audioscrobbler, Lazy search, Weather/Date/Time screensaver. 'Use Itunes' is selected.

I've just upgraded from 6.5.1 to 6.5.3. This got rid of the problem I had with my Apple Lossless tracks where it would skip the last few seconds of each track. However I have a new problem... When I'm listening to an Apple Lossless track and skip to the next one, I encounter a long pause. Doing some very simple analysis, I can see in task manager that alac.exe is grabbing a lot of CPU cycles, approx 60% usage. I can also see on my simple network monitor tool that a lot of downloading occurs when I hit the skip button.

It seems to me that when skipping an Apple Lossless track, the slimserver is processing the remainder of the track, then once it has been processed it starts playing the next one. Anyone seen this?

As a control, I played an album encoded in MP3, skipped some tracks, and didn't get this. However I did notice that when I played an Apple Lossless track, then selected an MP3 track, I got this waiting period again which led me to the conclusion that the slimserver is processing the whole of the Apple Lossless track before progressing with the MP3.

Thoughts/suggestions??

Thanks for your help.

Mark Lanctot
2007-08-14, 08:45
Does any of this change when one or the other is wired (SlimServer or Squeezebox)?

The reason I ask is, it could be waiting for the buffer to get to an acceptable level before playing - which is why you see so much downloading and why the processor usage is so high, it's trying to transcode as much of the track as it can in order to fill the buffer.

slimpy
2007-08-14, 09:02
Does any of this change when one or the other is wired (SlimServer or Squeezebox)?

The reason I ask is, it could be waiting for the buffer to get to an acceptable level before playing - which is why you see so much downloading and why the processor usage is so high, it's trying to transcode as much of the track as it can in order to fill the buffer.
I thought of this also but it doesn't explain the same behaviour when skipping to an mp3 which uses less bandwidth. Skipping from mp3 to mp3 doesn't exhibit this problem at all.
I think nuttyphilt was spot on with his analysis. It must be the transcoding process.
As I don't have any Apple Lossless tracks I cannot test this. But I'm sure it's not a general transcoding problem. My slimp3 (server side flac-mp3 transcoding) skips to the next track instantly.

-s.

nuttyphilt
2007-08-14, 09:03
Does any of this change when one or the other is wired (SlimServer or Squeezebox)?

The reason I ask is, it could be waiting for the buffer to get to an acceptable level before playing - which is why you see so much downloading and why the processor usage is so high, it's trying to transcode as much of the track as it can in order to fill the buffer.

I see where you're coming from but that wouldn't explain why the problem manifests itself if I play an Apple Lossless file, then skip to an MP3.

Edit: I'm too slow, you beat me to it!

Eric Seaberg
2007-08-14, 09:06
I've got an Inspiron 700M that I use only when necessary since I'm mainly a Mac guy. There's no way I'd try to run the 700M as a server UNLESS I were playing FLAC or something that Slim wouldn't have to transcode... the processor just doesn't have the headroom IMHO.

My server is a Mac MINI Core2Duo Intel @ 1.8GHz using Apple Lossless as my format of choice. Even when it has to transcode to something else, usually calling Quicktime, the MINI works a little hard to play without pauses, but it can do it.

I would still attempt to do it wired like Mark recommends, but it's probably your processor more than anything else. Try it using FLAC files, or at least something Slim can play natively without transcoding, and see if it makes a difference.

Mark Lanctot
2007-08-14, 09:08
I thought of this also but it doesn't explain the same behaviour when skipping to an mp3 which uses less bandwidth.

Yes, I read too fast and missed that part.

nuttyphilt
2007-08-14, 09:16
I've got an Inspiron 700M that I use only when necessary since I'm mainly a Mac guy. There's no way I'd try to run the 700M as a server UNLESS I were playing FLAC or something that Slim wouldn't have to transcode... the processor just doesn't have the headroom IMHO.

My server is a Mac MINI Core2Duo Intel @ 1.8GHz using Apple Lossless as my format of choice. Even when it has to transcode to something else, usually calling Quicktime, the MINI works a little hard to play without pauses, but it can do it.

I would still attempt to do it wired like Mark recommends, but it's probably your processor more than anything else. Try it using FLAC files, or at least something Slim can play natively without transcoding, and see if it makes a difference.

I don't think it's the laptop. It's a pretty powerful version of the 700M and I've had no issues at all until I upgraded from 6.5.1 to 6.5.3. As I said in my first post, MP3 files are perfect.

I think in my case I'm seeing the issue because my music is stored on a network drive and this is the slow link in the system. If I had the music stored locally, I think the pause could be as low as a second, instead of several seconds. However it still looks to me like the transcoding process for Apple Lossless has got a bit screwed up in 6.5.3.

slimpy
2007-08-14, 09:38
I think in my case I'm seeing the issue because my music is stored on a network drive and this is the slow link in the system. If I had the music stored locally, I think the pause could be as low as a second, instead of several seconds. However it still looks to me like the transcoding process for Apple Lossless has got a bit screwed up in 6.5.3.
That explains the download you see in your network monitor. It's not data streaming to the SB but data transfer from the NAS.
If the Apple lossless files were local you wouldn't see any network traffic as long as the alac process is running.
I think the main problem is that the alac process is not properly killed when you skip to the next track. I don't think it's the processor. Lossless to lossless transcoding doesn't use much computing power.

-s.

nuttyphilt
2007-08-14, 09:43
That explains the download you see in your network monitor. It's not data streaming to the SB but data transfer from the NAS.
If the Apple lossless files were local you wouldn't see any network traffic as long as the alac process is running.
I think the main problem is that the alac process is not properly killed when you skip to the next track. I don't think it's the processor. Lossless to lossless transcoding doesn't use much computing power.

-s.

Agreed. What are the next steps to logging a bug for this?

I'm going to downgrade to 3.5.2, then back down to 3.5.1 to see if I can isolate a version, then I'll report back later.

bpa
2007-08-14, 10:23
There is a big change in handling between 6.5.2 and 6.5.3 - in 6.5.3 SS no longer uses socketwrapper which caused other problem such as the cut-off.

The last time I saw problem with ALAC start delays - it was with Vista and due to interaction with iTunes library DLLs which are used by alac.exe.

nuttyphilt
2007-08-14, 23:49
There is a big change in handling between 6.5.2 and 6.5.3 - in 6.5.3 SS no longer uses socketwrapper which caused other problem such as the cut-off.

The last time I saw problem with ALAC start delays - it was with Vista and due to interaction with iTunes library DLLs which are used by alac.exe.

I downgraded to 6.5.2 and all is good, no cut-offs, and no pausing between skipping tracks.

I then upgraded to the latest daily build and I couldn't even play any music. Not sure if I have to re-scan my library but I didn't have time so didn't...

6.5.2 is the one for me. In the meantime I'll log a bug for 6.5.3.

Cheers.

bpa
2007-09-20, 01:57
I think I found your problem - I cannot find your bug report so I logged it as bug 5521

I think the problem has two sources: socketwrapper and Alac.
Before 6.5.2 socketwrapper hid the alac problem. Socketwrapper had other bugs which were fixed in 6.5.3 in addition the code was changed so that socketwrapper was no longer used with alac. This meant since 6.5.3 Alac bug the showed up.

It would be useful if you could test the updated Alac with 6.5.4 (or 6.5.5 nightly) and see if it cures your problem.

Instruction in this post
http://forums.slimdevices.com/showthread.php?p=228294#post228294

nuttyphilt
2007-09-20, 02:09
Apologies, I never got around to filing the bug report...

Thanks for fixing the problem, I'll have a look at this over the weekend and will report back here.

Cheers.

nuttyphilt
2007-09-23, 09:39
Yep - all looks good now. Tested with 6.5.4.

Thanks very much.