Many thanks for your contributions!!
I have pushed your changes in a dedicated branch there:
http://savonet.hg.sourceforge.net/hgweb/savonet/savonet/rev/c24310265f03
<http://savonet.hg.sourceforge.net/hgweb/savonet/savonet/rev/c24310265f03>I
have looked at the code, it seems good. Liquidsoap can compile with the new
API without problem and it works..!
Unless some of the other devs have any further remark, I will merge it in
the default branch in a couple of days..
Romain
PS: again, if you wish to work directly with our hg I think we could grant
you a commit access..
2011/4/10 Niki Yoshiuchi <aplu...@gmail.com>
> So I think I'm done! The changes are as follows:
>
> streams are now of type ('a, 'b, 'c, 'd) stream, and stream_parameters are
> of type ('a, 'b) stream_parameters. The variants are compatible with ('a,
> 'b) Bigarray.kind. The first two are for the input channels and the latter
> two are for the output channels.
>
> All the channel formats have been implemented. I have switched them from a
> union type to type ('a, 'b) sample_format = int. This is in the style of
> Bigarray.kind.
>
> Callbacks have been implemented. They use two Genarrays (with the
> c_layout) and are of type ('a, 'b) and ('c, 'd). They only work with
> interleaved streams.
>
> read_stream and write_stream have been updated to respect the format type
> of the stream.
>
> read_stream_ba and write_stream_ba have been added, which use Bigarrays to
> prevent copying data. If the streams are non-interleaved a minimal amount
> of copying is done.
>
> Pa_Sleep has been implemented.
>
> Device information has been added.
>
> As always the code is available on github:
> https://github.com/aplusbi/ocaml-portaudio Please let me know what you
> think and if any changes are necessary.
>
> -Niki Yoshiuchi
>
>
> On Tue, Mar 22, 2011 at 11:30 AM, Romain Beauxis <to...@rastageeks.org>wrote:
>
>> 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
>> >>>
>> >>
>> >
>>
>
>
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Savonet-devl mailing list
Savonet-devl@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/savonet-devl
