Qtox: Failure to open audio device results in spam in qtox.log
Brief Description
OS: Windows
qTox version: (version numbers in menu Settings → About) v1.4.1-1-g06d78dc.
Commit hash: 06d78dcdee7bfe9a320fe91662f34227d74c3916
toxcore: 0.0.0
Qt: 5.5.1
Hardware: Not relevant
…
Reproducible: Always
Steps to reproduce
- Have an audio device with a name that contains "ö"
- Make qtox try to play audio
- Check the qtox.log file
Observed Behavior
My qtox.log file is 51GB in size.
Expected Behavior
My qtox.log file should not be 51GB.
Additional Info
(links, images, etc go here)
Sample log file:
sample log.txt
dongmaster
All 9 comments
Note: the problem is most likely worked around in 93991368c6202fc9dfe474ad1e9ba5668c8a1e7b, but fixing the actual problem is needed. I.e. with new release logs won't grow that big in size, but spam will still be there.
@antis81 the rework of audio and moving away from openal to RtAudio should help with this, right?
zetok
on 14 Jul 2016
Could this possibly be related to https://github.com/tux3/qTox/issues/2973 ?
Audio did not work at all in qtox at that point in time, probably because qtox couldn't open the audio output.
But I have since updated qtox and audio works and I did not notice any error lines regarding audio near the end of the 51GB log file so maybe the audio issue is fixed?
dongmaster
on 14 Jul 2016
Maybe. If log won't grow in size that big, then it's just #2980, which is not included in v1.4.1.1 release.
zetok
on 14 Jul 2016
Oops, wrong issue number, I meant #3440.
zetok
on 14 Jul 2016
the rework of audio and moving away from openal to RtAudio should help with this, right?
Yeah, it would fix it. The problem is, that OpenAL encoding in Windows is not UTF-8, but asumingly Codepage Windows-1252. This is internal to OpenAL and cannot easily be fixed. AFAIK it got fixed in OpenAL-Soft, but as we rather require the stuff from RtAudio, it is not worth the effort IMO to fix it beforehand. I made a branch to start RtAudio implementation and as said before, we need to do it in parallel, so it doesn't affect existing features. So, if someone wants to fix it right now, feel free to do so.
antis81
on 14 Jul 2016
@antis81 Is your branch already public? I'd be interested in helping out with that :)
sudden6
on 16 Jul 2016
Is your branch already public? I'd be interested in helping out with that :)
No, but I'll make it public today, so we can add PR's based on that one… :)
antis81
on 17 Jul 2016
@sudden6 We can now start! :) -> See #3524. Please post your ideas.
antis81
on 17 Jul 2016
This is no longer a problem.
sudden6
on 11 Aug 2019
Related issues
akhilman
·
7Comments
tox-user
·
4Comments
ghost
·
6Comments
dxerw
·
5Comments
andriusign
·
4Comments
Most helpful comment
Yeah, it would fix it. The problem is, that OpenAL encoding in Windows is not UTF-8, but asumingly Codepage Windows-1252. This is internal to OpenAL and cannot easily be fixed. AFAIK it got fixed in OpenAL-Soft, but as we rather require the stuff from RtAudio, it is not worth the effort IMO to fix it beforehand. I made a branch to start RtAudio implementation and as said before, we need to do it in parallel, so it doesn't affect existing features. So, if someone wants to fix it right now, feel free to do so.