[Onslaught]

How did you setup smb? SMB type of source of mapped network drive?.

Unfortunately I do not really understand the question.
I have a Windows 2003 Server running as a file server. In XBMC I have just added the shared folders through "Add source".

There seems to be something in smb+flac that takes too long for an Atom and we get a glitch...

Yes, this seems to be the case. However this is XBMC specific, I have no problems playing the FLAC files with WASAPI in Foobar.
Also XBMC playing the FLAC files on SMB through Direct Sound is not a problem either.

A few things to try:
- Map the drive with Windows and add the drive as a source if that's not what you're doing already
- Try the files without tags.

Ok, I will try with mapping the drive in Windows instead of relying on SMB network sharing.

To remove the tags should I use MP3Tag? Does it support Flac tag removal?

[MajorTom]

I am also streaming through SMB. I just shared the whole drive (as I always have) on Windows 7, using the old login/password method not HomeGroup (which I believe is the method you suggested). I will try removing the tags to see if this makes a difference. As onslaught has pointed out this only occurs with WASAPI not DirectSound so I'm not sure how this could be a network issue?

@Onslaught - MP3Tag is awesome (and free!) and works great with FLACS.

[paulpoule]

GREAT !!!!

I replace SMB access to mapped network drive and it works fine!!

Thanks a lot for your help CrystalIP.

[Onslaught]

CrystalP: You were correct! When I mapped the SMB share as a network drive in Win 7 the stutter disappeared.

So this solves the problem for me, at least temporarily. However I still believe that this is a bug that should be taken care of. More and more will use Win 7 and I also assume that many will be using SMB as I have.

MajorTom: What are your findings, does this solve the issue for you?

Thank you both for the tip about MP3Tag, I will need to check this tool out.

[Onslaught]

GREAT !!!!

I replace SMB access to mapped network drive and it works fine!!

Thanks a lot for your help CrystalIP.

Hehe.. Both posting at the same time...

[MajorTom]

Oh right, I get it... will have a go and report back. Cheers!

[paulpoule]

Hehe.. Both posting at the same time...

[MajorTom]

Thats seems to have fixed it all right.... You learn something every day :-)

[CrystalP]

Sure that's more a workaround than a real fix. There is something slow in the smb code.
Alternatively the WASAPI audio buffer may be smaller than the DirectSound buffer.

[MajorTom]

Sure that's more a workaround than a real fix. There is something slow in the smb code.
Alternatively the WASAPI audio buffer may be smaller than the DirectSound buffer.

I think the WASAPI audio buffer has already been increased once (I remember seeing it go through SVN)... I thought at the time that that had improved the stuttering somewhat but not fixed it... So maybe the buffers could be compared (DirectSound vs WASAPI) to see what the difference is...

As you say though, can't rule out the SMB code either...

[Onslaught]

So what is the next step?

Should we log a bug report in TRAC? Or could we start with comparing buffer sizes between Direct Sound and WASAPI?

[CrystalP]

There is related fix in trunk (r35084).

edit: and please try files with stripped tags. That would help pinpoint the part that causes a problem.

[WiSo]

There is related fix in trunk (r35084).

Note that FileSMB isn't in use on win32. I already asked elupus about adding getchunksize to Winfilesmb but he said it should be buffered internally and not needed on win32 (might need a test with wireshark)

[neil_g]

slightly off topic but this SMB stutter issue.. could it cause stuttery video playback also?

[HeresJohnny]

Yes, the stuttering continues. IMHO the root of this is because the buffer is too BIG. By default <cachemembuffersize> is set to 5MB. This seems fine for playback of web trailers and the like to avoid reloading. However, reloading a buffer of 5MB while streaming can be potentially disastrous depending on network congestion. The WASAPI component seems to have slightly bad programming in that the file already starts playing while the buffer is not yet full... at least that's what it sounds like since stuttering on large files for me starts occurs at the beginning .

If you primarily listen to music, I'd suggest trying a value of ~1MB. This is my advancedsettings.xml:

Code:

<advancedsettings>
        <audio>
                <dvdplayerignoredtsinwav>true</dvdplayerignoredtsinwav>
        </audio>
        <network>
                <cachemembuffersize>1442880</cachemembuffersize>
        </network>
</advancedsettings>

Please report back if that helped your problem.