First of all, how to reproduce:
1. Open blender.
2. At top bar, where it is written "SR:2-Model" (just at right of "Help"), select "4-Sequence".
3. Inside middle window, add any video with audio, or just an audio file.
4. While mouse is over this middle window (or at anywhere else), press Alt+A to make blender play the sequence.
What should happen: the sound should be played.
What actually happens: no sound, and the following message is printed on terminal:
Couldn't open audio: No available audio device
If you try to render the movie (using "ANIM" button, and maybe editing some options nearby), the generated .AVI movie will have sound, but blender will still not play it.
Looking at Blender FAQ:
They suggest two things. I also found similar suggestions at comments of one ubuntu bug:
In summary, what I discovered is that blender sound support in Linux is still very bad (I guess, but I'm not sure, it tries to use OSS sound, but a grep in blender sources found nothing about OSS), this is still an old issue (I found a blender bug report about this from year 2004), but it will work if you set the following variable:
Maybe, for some users, "blender -g noaudio" must also be used, but in my case the above variable is enough (and from what I read, for many users that's enough too).
The blender FAQ is misleading, because it tells us about a lib in debian systems and also tells us to set that variable to "esd", which makes no sense for me, since I don't use any sound daemon.
Related blender bug reports:
So... You must be asking... What you from Gentoo can do about this? I have two answers, one complicated and one simple:
1. Edit blender source-code and fix this bug there.
2. Add a little launcher script that should just set this variable and call blender binary.
The second solution is trivial, and should work.
Finally, if the launcher script is used, I would suggest the following changes too:
-> a simple 2-line launcher script
-> the actual blender binary
-> everything that is currently placed at /usr/share/blender should now to go into this .release directory.
I discovered (using strace) that blender searches for <blender_binary_dir>/.release/ and loads plugins and python scripts from that directory.
If above suggestions are accepted, then bugs #131139 and #135574 might be fixed as well.
Huh... Just a typo. The directory should be /usr/share/blender/release/, and NOT /usr/share/blender/.release
I also found (through strace) that blender tries to find .Blanguages in:
But never in /usr/share/blender/.Blanguages, where it is located right now.
Also, I don't see any reference to ".bfont.ttf" in strace log.
Blender is known to be a pain about paths, please start filling bugs upstream about that, I tried to workaround the problems many times...
But, as I described above, the launcher script works. I've just tested it.
It can be a workaround while upstream does not solve these problems.
SDL_AUDIODRIVER=alsa could reside on env, I'll add an einfo about it soon.
I'm not exactly happy on wrapping blender just for it anyway...
It is not just for it. As I explained, wrapping blender and putting blender files in those directories solve other bugs too. Try it and see that Python plugins are recognized when you do those changes.
This is the script, in case you need:
SDL_AUDIODRIVER=alsa /usr/share/blender/blender "$@"
as I said, please add the bug items from the upstream bug tracker.
I'll try to provide a saner workaround for the path issues, the audio problem is just a configuration issue (add the var in your local env to solve it)
(In reply to comment #6)
> I'll try to provide a saner workaround for the path issues,
Please, mail me (or write a comment to this bug or to one of another related bugs) whenever you do it. I want to know what workaround will be choosen, and also I want a fully working (and this means with all Python plugins) blender.