problems in the first steps

[Christopher Proß]

Hello,
I have here here python 2.7.10 with windows 10 and I can't work with
libaudioverse.
Why, see this interactive python session:

D:\Programme\libaudioverse-master\libaudioverse-master\scripts>python
Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import libaudioverse
>>> s=libaudioverse.Server()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Python27\lib\site-packages\libaudioverse\__init__.py", line
532, i
n __init__
handle = _lav.create_server(sample_rate, block_size)
File "C:\Python27\lib\site-packages\libaudioverse\_lav.py", line 239,
in cr
eate_server
err = _libaudioverse.Lav_createServer(sr, blockSize, ctypes.byref
(destination))
WindowsError: exception: access violation writing 0x00000000
>>>

Can someone help me by this interesting error?

best regards
Christopher Proß

[Chris Norman]

Hi,

Don't forget to call initialize first.


import libaudioverse as lav

lav.initialize()

server = lav.Server()


HTH,

[Christopher Proß]

Hi,

ok, that is a very stupid mistake!

But thank you...

hth

[Austin Hicks]

Yeah, it's not good about telling you it's not initialized


I was going to tell you about how putting in an error is expensive and
that I don't want to do it for that reason, but then i realized that
really all we need to do is check at the top of Lav_createServer because
everything that can be used without one can already be used before
initialization. Shame I didn't think of this sooner.

[Christopher Toth]

If everything can be done without one, is an explicit initialization
step required at all? Just have the library do it if it's not done when
you create the server, refcount servers, when they go to 0, uninitialize.

--
-Q

Accessible Software for the Blind
http://GetAccessibleApps.com

[Austin Hicks]

This actually doesn't work with device enumeration, which will probably
never require an object. It's effectively a singleton, but not exposed
through the usual create/destroy pattern because that's very heavyweight
and there's no circumstance in which you'd want more than one.
Internally, this is using some library-global data for the audio device
factories.


Also, making Lav_initialize optional in future is something I can do,
but putting it back in requires a version bump and everyone to change
their code. Until I'm really amazingly sure that it's what I want to
live with, I'm not going to; whether or not initialization is optional
can change because of the smallest internal detail

[Chris Norman]

Alternatively, could you just have the bindings do it when they are
imported? That seems a little excessive, but it would have the benefit
that if you changed the C portion in the future only the bindings would
have to be updated, not everyones' code.

HTH,

[Austin Hicks]

You still have to call shutdown. And if you do it there, you're going
to end up having weird code like this:


try:

import libaudioverse

except LibaudioverseError as e:

log_what_went_wrong(e)


Except I honestly have no idea how you catch specifically Libaudioverse
errors because the module wasn't imported, so you'd probably have to
catch anything.


99% of the time init is just going to work. The remaining 1% of the
time, you need to either put up a dialog or log it or something. Just
crashing isn't acceptable. Importing libaudioverse also happens before
you put logging in place, so you can't see what init decided to (or not
to) do.

No one is going to manage to convince me to kill the init function. No
one is going to convince me to make init implicitly happen if you
forget. The most I might do in this area is a context manager so that
your Python app can properly shutdown even if it crashes. I.e.:

with libaudioverse.InitializerManager():
#your main function here.

And of course the previously discussed error on a few functions. I
consider it to have been a problem previously, but it's not anymore.
Somehow, I didn't realize it's only 5 or 6 functions only. I thought it
would have to be all of them. If it had been, the cost might have been
too prohibitive for phones in future. People using the Python API on
desktop would have never noticed, but anyone trying to use the C++ API
on phones (when I do that) might have, especially since I'm already
thinking of ways to get rid of the locks and let you run Libaudioverse
as part of your main loop if you want.