Hi !
2011/3/22 Niki Yoshiuchi <aplu...@gmail.com>:
> Thanks for the feedback. I've done a little more work on it - I
> rewrote the original read/write functions so they now take a `'a array
> array` and I renamed my Bigarray implementations to stream_write_ba
> and stream_read_ba. I also added functions to retrieve information on
> the Host API and devices.
Excellent !
> I've been considering adding additional type info to the stream type.
> For example, if you open a stream with the format `Format_float32`,
> the type returned would be `float stream`, or possibly something more
> complex like ('float, Format_float32, non_interleaved) stream. That
> way the type system would ensure that you never try to using a float
> array on a Format_int32 stream. I'm pretty sure this can be added
> without the need to change any code that is currently using the
> portaudio library as well.
Indeed; Variant types should be interesting for that.
Basically, you can use a type of the form:
type format = Float32 | Float | ...
type 'a stream
Then in the .ml code, you can force each open function to return a
variant of 'a stream with the appropriate type.
In case, you can use Obj.magic and the .mli to force the type to have
the right variant.
You can look at the code of ocaml-flac for an example. In the code, I
have added variant for native and ogg flac that allows to use the same
API with the two different type of format..
> Additionally I feel that it might be best to remove the code I've
> added for callbacks. I should do some more testing on a faster
> computer, but as I mentioned it's rather fragile on my netbook. Given
> the limited usefulness of the feature and the fact that it requires
> OCaml 3.12 and linking to the thread library, I think the cons
> outweigh the pros. Perhaps it could be a compile time check?
Well, my problem is that I do not know what callbacks are good for :)
Making it optional a configure-time would indeed be nice for backward
compatibility purposes..
> Finally, I noticed that `open_stream` is commented out in the mli
> file. Is there a reason for this?
That I do not know. Maybe Sam has a better insight on this..
Thanks for your work!!
Romain
> -Niki Yoshiuchi
>
> On Tue, Mar 15, 2011 at 8:15 PM, Romain Beauxis <to...@rastageeks.org> wrote:
>> Hi again!
>>
>> 2011/3/15 Niki Yoshiuchi <aplu...@gmail.com>:
>>> I've been using ocaml-portaudio for some pitch-detection software I'm
>>> working on. I noticed that some functionality was missing and decided
>>> to add it in. Specifically I've been working on: different formats,
>>> callbacks and using Bigarrays.
>>>
>>> I don't know how useful callbacks are - if the execution of the
>>> callback takes too long portaudio will silently fail (pun intended).
>>> On my machine (an EeePC 1000H) the callback couldn't handle much more
>>> than a Bigarray.blit. Generating random noise, for example, would
>>> cause the thread to terminate execution after a few seconds. This
>>> also requires OCaml 3.12 and the use of threads.
>>
>> I have no idea if callback are useful but I see that the code for this
>> seems very clean and makes use of the thread registration API provided
>> by ocaml 3.12. Very nice :-)
>>
>> My only remark would be about the use of printf which is probably
>> temporary for debugging..
>>
>>> The other significant change I've made is switching to Bigarrays.
>>> This results in far less copying of data and allows for almost
>>> seamless use of non-interleaved arrays. I have noticed that Liquid
>>> Soap uses float array arrays extensively and that Bigarrays will break
>>> compatibility. While I have currently rewritten the read and write
>>> functions to use Bigarrays I can easily support both in order to not
>>> break compatibility. However this leads me to wonder (and forgive me
>>> if this is an ignorant question, I don't use Liquid Soap and only
>>> briefly looked through the source) why float array arrays are used
>>> over Bigarrays given that Bigarrays are compatible with C.
>>
>> I think the answer is that we consider that copying float arrays is
>> negligable compared to the advantage of being able to manipulate
>> directly floats in OCaml code in Liquidsoap.
>>
>> For video data, however, we are using bigarrays because copying data
>> is just not an option there..
>>
>> It would be nice indeed to have a backward compatibility API. You may
>> switch the main function to bigarray and provide an alternative _f API
>> though..
>>
>>> My code can be found on github:
>>> https://github.com/aplusbi/ocaml-portaudio Some functionality is
>>> still missing or untested, but please let me know if any of this work
>>> is of use to Savonet.
>>
>> I think we would be pleased to incorporate your changes once you are
>> done. I also believe that we would be pleased to give you commit
>> access to our repository if you wish to work directly there..
>>
>> Romain
>>
>>> Thanks,
>>> Niki Yoshiuchi
>>>
>>> ------------------------------------------------------------------------------
>>> Colocation vs. Managed Hosting
>>> A question and answer guide to determining the best fit
>>> for your organization - today and in the future.
>>> http://p.sf.net/sfu/internap-sfd2d
>>> _______________________________________________
>>> Savonet-devl mailing list
>>> Savonet-devl@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/savonet-devl
>>>
>>
>
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Savonet-devl mailing list
Savonet-devl@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/savonet-devl
