One of our users reported an issue with FMOD Studio API 2.00.07 not playing specific audio link (public jira) and that link supposedly works if he inserts ip instead of dns. Link also works if provided to FMOD Ex version of our product. Our QA encountered same behavior (Notes: plays only for specific testers, OS independent) and confirmed that issue does not repro with FMOD Ex. Link appears to be valid and works from both browser and media player.
According to user it is related to ipv6 being available at both user and server sides and upon checking it I discovered that fmod fails to play ipv6 links like http://[::1]/file.mp3 (My provider provides no ipv6 so I had to start my own http server, original link plays without issues for me), at the moment user’s guess about this being ipv6 issue appears to be plausible.
Our product provides link directly to mSystem->createStream(url.c_str(), …) and later calls getOpenState(), which returns FMOD_OPENSTATE_ERROR state. Since Link is valid and plays at FMOD Ex and in other software this appears to be FMOD Studio API specific issue.
So I have some questions:
Does FMOD support ipv6?
What are my options to work around ipv6 if it’s the cause of the issue?
How can I figure out accurate reason for that specific link not playing? Profiling tool that comes with core api do not appear to have any kind of logs.
Firstly I tested the audio link in our netstream example and it worked for me, however it connected as an ipv4 socket. Secondly I tried the public jira link (I even created an account) but I cannot see what’s there, so if there is more info please repost here.
FMOD does not currently support ipv6 URLs, our parser isn’t sophisticated enough to handle those. That’s why passing in [::1] as the URL failed. However I tested our networking layer (bypassing the parser) and found it is working well for my ipv6 local server test. So in theory with a fully ipv6 network stack and an appropriate named URL things should “just work”.
One possible difference between FMOD Ex and FMOD Core API is FMOD Ex always forced sockets to be ipv4 where as the new code uses a more generic socket function that will negotiate ipv6 if available. I’d prefer to keep moving the envelope further regarding ipv6 and as such will issue a task to fix our parser. However I feel that’s unrelated to this issue.
Some logging output from FMOD from a customer with ipv6 problems may help diagnose what’s going on.
I attached logs to google disc since I’m incapable of uploading files here.
Here is what looks like relevant part:
[LOG] AsyncThread::threadFunc : Starting Asynchronous operation on sound 00000235ACC798B8
[LOG] SystemI::createSoundInternal : Create name=‘http://streamplus14.leonex.de:38680’, mode=0x02010088
[LOG] FMOD_OS_Net_Connect : select timed out
[LOG] AsyncThread::threadFunc : Finished Asynchronous operation on sound 00000235ACC798B8
[LOG] SoundI::release : (null) (00000235ACC798B8)
According our own log it was roughtly 5 seconds between start and finish, if you need more specific logging please specify needed flags. Log is from one of our testers.
Public jira contains only original report from user. Sorry, was not aware that our public jira requires logging in either way.
Thanks for the information. I’ve been doing some research into how ipv6 is handled in this context and I’m pretty confident that I have a solution. I’m aiming to have a fix in 2.00.11 that should resolve this problem.
Specifically what I am doing is allowing FMOD to fallback to ipv4 if the DNS returns more than one result. This happens if the target supports both ipv6 and ipv4. This solution is better than what FMOD Ex does, where it always forces ipv4, this should allow both protocols to work where appropriate.