Cannot set position when serving on localhost

[brandonchinn178]

I'm running a Django project at http://localhost:5000, and the following code segment in the console doesn't work:

sound = soundManager.createSound({url: "/media/audio/foo.ogg"})
sound.play({position: 1000})

where /media serves files from my local filesystem. It also doesn't work if I give the full path http://localhost:5000/media/audio/foo.ogg.

However, it does work if I load from any external site or if I load the file and use the url from URL.createObjectUrl. The biggest difference I can find is that loading from localhost returns 200 responses, while loading externally or with a file blob returns 206 responses. I can't find any documentation about this, but if this is documented somewhere, please point me to it. For now, I could manually check the domain and load a file blob, but I'd like to know why this is happening before trying any workarounds.

[alumae]

I have the same problem when the server that I load my audio from doesn't support partial request (206). In this case, setPosition(..) also has no effect. You can test it with a file http://bark.phon.ioc.ee/tsab/audio/?id=8652&fragment=2.

It occurs only when the HTML5 client is used. It works with no problems with the Flash client.

[scottschiller]

Ah yes, keep in mind that HTML5 will by default try to use partial / byte range requests. If your server doesn't indicate support, then the client should fall back to a traditional "progressive" request where it grabs all bytes in sequence. However, this is less efficient than byte serving and doesn't allow efficient arbitrary seeking within sounds, particularly larger ones (as an example, jumping to arbitrary time in a lengthy YouTube video works thanks to byte serving.)

A bit more on how clients make requests: http://www.schillmania.com/projects/soundmanager2/doc/technotes/#client-requests

(Was on vacation, apologies.)

[brandonchinn178]

Thanks for getting back Scott! For me, the problem isn't inefficiency when seeking, it's that setting the position had zero effect. I was using an ogg file of a couple KB, so it's not size that's the issue. Does setting position not work with 200 responses, or is it another issue?

[scottschiller]

Thanks for the note. Maybe this is somehow an effect of the OGG being really small in size (assuming you meant KB and not MB or something.) Hrm.

If you're requesting the file locally from disk (not over HTTP[S]) and running into issues, I'd wager the issue is with the file or the way it was encoded. If the file is loading via HTTP, there's the possibility of range/partial requests playing a role.

Another quick test, something to try - drag the file into a Chrome tab, or try file -> open and load it locally. SM2 uses the standard HTML5 API to set position etc., and the built-in audio player the browser uses to play files should behave similarly. If you can't seek when loading the OGG directly in Chrome, perhaps Chrome itself is having trouble seeking within or playing the file.

You can compare behaviour to Firefox which should also support OGG, and see if the playback / positioning stuff is consistent there.

[brandonchinn178]

I can seek when loading the OGG directly in Chrome. It's only when loading with soundmanager.

[scottschiller]

Dang, interesting. OK, it sounds like perhaps the network plays a role in throwing things off here - assuming you were loading it from disk, i.e., file://, vs. over the network.

I didn't explicitly mention it above, but try navigating directly to the OGG URL in Chrome and see if it loads OK there and seeking works. SM2 should be doing the same thing, as the Audio() object should be the same as what's used when you load a URL directly or drag-and-drop a sound file right into the browser.

[brandonchinn178]

I don't quite understand the distinction. Either dragging and dropping the file or going to file:///Users/Brandon/Desktop/test.ogg in Chrome. I've shared the file below, so you can see if it works for you.

https://drive.google.com/file/d/0B9Jfhak3pilwcTA0S29BMXYyUlE/view?usp=sharing

[scottschiller]

@brandonchinn178 Pardon the late reply, here. Interestingly, downloading that file and playing it locally in Chrome seems to be just fine. So, that's good; eliminating the network aspect, it appears seeking and playback works just fine. So Chrome is able to load and decode the OGG sound. 🎉

When loading the sound over HTTP from a vanilla apache install on my Mac, I'm able to load and seek within the file from one of the SM2 homepage demos - just changing the URL to point to test.ogg instead of one of my own. So, I suspect something with the way you are serving up the file playing a role in this case.

I suggest doing a test with an MP3 or a few other files, and see if the seeking behaviour is problematic for other file types as well. Something doesn't sound quite right!

[brandonchinn178]

hm possibly. I'm getting it via Django, so possibly something on that end. I'll let you know later; I'm working on another section of the code. But don't close this issue, I'd like to revisit this when I come back to this. Thanks!

[Deiber]

@brandonchinn178 I had a similar Issue #175 , but in my case was only for Chrome browser and I fixed it implementing the header "Accept-Ranges": "bytes" within the response from the Django Server. Maybe it can help you!

[brandonchinn178]

Thanks, I'll look into it!

[scottschiller]

Accept-Ranges: Bytes should help here. Range requests / partials are important to HTML5 clients as most expect they can ask for arbitrary slices of files. I wouldn't trust most browsers to work properly when they're told by a server that they can't. 😬

A few related notes on this, yonder - http://www.schillmania.com/projects/soundmanager2/doc/technotes/#byte-serving

(Pardon super late follow-up on this.)