Great thanks!
It would probably make sense for me to have access to the hg repo in case
there are any features/bugs that need work in the future.
-Niki
On Mon, Apr 11, 2011 at 1:01 PM, Romain Beauxis <to...@rastageeks.org>wrote:
> 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
