View Full Version : Stuttering m4a playback under Vista with Squeezebox

2007-11-06, 14:28
I just thought I would post a summary of the issues (and the solution) I have been having recently. My apologies if this has been covered in any other threads on this forum.

Firstly, the symptoms. AAC (ripped with iTunes) stuttering badly during playback, MP3s were fine. Previously all had been fine.

After a bit of research here and elsewhere I tried mplayer instead of mov123, I may have cocked this up somewhat as I had no joy.

After a lot more buggering about I discovered that the Quicktime player, which slimserver uses for transcoding, gave the same stuttering results on the PC. A re-install of Quicktime improved nothing, nor did the latest 5 November 7.3 version.

Much googling later I discovered references to problems with Quicktime playing video files on SATA drives connected to Nvidia Nforce4 chipsets.

Recently I had moved my music library from a PATA drive to a new SATA connected on a Nforce chipset. My motherboard has 4 NVidia SATA connects and 4 Silicon Image SATA channels. I copied a few m4a's to a drive on the Silicon Image controller and tried it via QT, it played fine. I tried via SS+SB, it played fine. I tried some more, fine. Happy days.

I tried installing the latest Nvidia drivers but they didn't help.

In short, QT on Nforce4 looks like its broken. The work around for me is to store your aac/m4a on a non-Nvidia connected drive.

I hope this helps someone else.

2007-11-06, 15:36
You should try mplayer again.

If you are using 6.5.x did you follow the steps in post 16 of this thread

Ignore the socketwrapper comments as they were sorted in 6.5.4.

2007-11-07, 01:43
I'll give mplayer another try when I get the time.

I was fortuante enough to be able to swap the drive with the music on from the NVidia controller to a SiL controller instead.

It makes you wonder how QT is tryin to access the drive for it to be broken in such a way. I can't beleive that the problem lies with NVidia as I would expect other similar media player apps to have issues too.

2007-11-07, 07:26
The simplest explanation is that the NVIDIA chipset/firmware is introducing occasional delays which are larger than the Quicktime buffer can cover. Or that there's a bug in the Quicktime buffering.

This is pure conjecture - I have no facts at all.

2007-11-20, 06:02
I'm having the same problem on Vista, however my CDs are ripped to FLAC using Winamp.

I did wonder whether it was the auto-indexing of drives that Vista does (constantly reading the drive), however I've not yet tried switching it off to see if the stuttering stops.

2007-11-20, 08:46
I have the same issue, I have 3 SATA drives connected to an NForce4 motherboard running RAID 5. Right now I'm using SlimServer on another server that isn't using a SATA drive to get around this issue.

2007-11-20, 08:55
How are you getting on with that?

I have a spare drive which I might install on IDE and use that for Slimserver music.

2007-11-22, 06:37
Much googling later I discovered references to problems with Quicktime playing video files on SATA drives connected to Nvidia Nforce4 chipsets.

I appreciate this information, as I was one of the people suffering from broken playback of any .m4a encoded in iTunes as well as DRM-free music purchased off of iTunes. I too have SATA drives (in RAID-0 in fact) running via an nForce4 chipset.

That said, I just updated to iTunes and my issue - for now - seems to have been corrected (knocks on wood). If you get a chance, try 7.5 and slap some .m4a's back onto your nForce4 drives and test it. I'd be curious to see what happens.

Lastly, trying mplayer was beyond my technical prowess (also thanks for trying to help me, bpa)!

2007-11-24, 14:03
I've just installed an IDE hard drive into my PC, which has nothing on it other than 3 albums. I have turned off all scanning and indexing of this drive to ensure that it is not in use unless I am playing music.

I am still getting the stuttering on playback.

Its not the rip as it plays fine on my PC, I have also tried different channels on my wireless router.

None of which have worked. Next stage is to try the latest slimserver software.

If that doesn't work I'm going to sell the Squeezebox as it won't be fit for purpose!

2007-11-24, 14:24

This thread is specifically trying to sort a problem with a user and AAC encoded files. This problem has been shown to be due to Quicktime.

If your files are not AAC/M4A encoded then you would be better off starting a new thread to get help as there few readers of this thread due to the specific nature of the title.

The common cause for stuttering is usually wireless signal strength and possible netwpork configuration and it would be better to work through the likely wireless problems first - I think a separate new thread for your problem would elicit help from many more readers.

If your files are AAC/M4A encoded, then you would well do install mplayer as an alternative to mov123.

I would recommend installing 6.5.5 first as there were many small problems with 6.5.2 and some Vista specifics.

2007-11-29, 20:21
I have tried using mplayer on Vista to get around the Quicktime issue but have had no success. The problem appears to be that mplayer is being executed directly without calling socketwrapper first, as a result, all that happens is a nice BIG file called "#PIPE#" is created on my hard drive!

mplayer works fine standalone and works fine with from the AlienBBC plugin (and in this case when AlienBBC plays a realaudio stream I see the socketwrapper being invoked) but for the life of me I can't see what is wrong with my "custom-convert.conf" which doesn't trigger socketwrapper!! Btw, I'm using the latest SqueezeCenter build.

== Start of custom-convert.conf

mov wav * *
[mplayer] -really-quiet -vc null -vo null -cache 128 -af volume=0,resample=44100:0:1,channels=2 -ao pcm:nowaveheader:file=#PIPE# $FILE$
mov mp3 * *
[mplayer] -really-quiet -vc null -vo null -cache 128 -af volume=0,resample=44100:0:1,channels=2 -ao pcm:nowaveheader:file=#PIPE# $FILE$ | [lame] --silent -r -x -q $QUALITY$ -b $BITRATE$ - -
mov flc * *
[mplayer] -really-quiet -vc null -vo null -cache 128 -af volume=0,resample=44100:0:1,channels=2 -ao pcm:nowaveheader:file=#PIPE# $FILE$ | [flac] -cs --totally-silent --endian=little --channels=2 --sign=signed --bps=16 --sample-rate=44100 --compression-level-0 -

=== End of custom-convert.conf

2007-11-30, 02:33
I think this may as a result of a change in SS/SC (possibly from 6.5.3 or 4) to minimise use of socketwrapper. AlienBBC works because it is playing a stream and has its own code to handles the "types".

Socketwrapper handles the #FILE# and #FILE# is needed because standard mplayer cannot output WAV to stdout. I think SC will not use socketwrapper when playing files of "known" types.

So to avoid changing any Slimserver code - what is needed is a AAC/m4a decoder which uses stdin/stdout.

Answer: faad. (see http://www.rarewares.org/aac-decoders.php )

Unfortunately I don't the additional command line options to make faad work but there are some Linux entries in the Wiki such as below - but I have not tested these to see if there changes needed for Windows.

# Transcoding for AAC files.
mov flc * *
[faad] -w -f 2 $FILE$ | [flac] -cs --totally-silent --compression-level-0 --endian little --sign signed --channels 2 --bps 16 --sample-rate 44100 -

mov mp3 * *
[faad] -w -f 2 $FILE$ | [lame] --resample 44100 --silent -q $QUALITY$ -b $BITRATE$ -x -r - -

mov wav * *
[faad] -w -f 2 $FILE$