defining r audio connections

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

defining r audio connections

frederik-2
Dear R Devel,

Since Linux moved away from using a file-system interface for audio, I think it is necessary to write special libraries to interface with audio hardware from various languages on Linux.

In R, it seems like the appropriate datatype for a `snd_pcm_t` handle pointing to an open ALSA source or sink would be a "connection". Connection types are already defined in R for "file", "url", "pipe", "fifo", "socketConnection", etc.

Is there a tutorial or an example package where a new type of connection is defined, so that I can see how to do this properly in a package?

I can see from the R source that, for example, `do_gzfile` is defined in `connections.c` and referenced in `names.c`. However, I thought I should ask here first in case there is a better place to start, than trying to copy this code.

I only want an object that I can use `readBin` and `writeBin` on, to read and write audio data using e.g. `snd_pcm_writei` which is part of the `alsa-lib` package.

Thank you very much,

Frederick

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: defining r audio connections

Duncan Murdoch-2
On 06/05/2020 1:09 p.m., [hidden email] wrote:

> Dear R Devel,
>
> Since Linux moved away from using a file-system interface for audio, I think it is necessary to write special libraries to interface with audio hardware from various languages on Linux.
>
> In R, it seems like the appropriate datatype for a `snd_pcm_t` handle pointing to an open ALSA source or sink would be a "connection". Connection types are already defined in R for "file", "url", "pipe", "fifo", "socketConnection", etc.
>
> Is there a tutorial or an example package where a new type of connection is defined, so that I can see how to do this properly in a package?
>
> I can see from the R source that, for example, `do_gzfile` is defined in `connections.c` and referenced in `names.c`. However, I thought I should ask here first in case there is a better place to start, than trying to copy this code.
>
> I only want an object that I can use `readBin` and `writeBin` on, to read and write audio data using e.g. `snd_pcm_writei` which is part of the `alsa-lib` package.

I don't think R supports user-defined connections, but probably writing
readBin and writeBin equivalents specific to your library wouldn't be
any harder than creating a connection.  For those, you will probably
want to work with an "external pointer" (see Writing R Extensions).
Rcpp probably has support for these if you're working in C++.

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: defining r audio connections

frederik-2

On Wed, May 06, 2020 at 02:26:34PM -0400, Duncan Murdoch wrote:
>On 06/05/2020 1:09 p.m., [hidden email] wrote:
>>I only want an object that I can use `readBin` and `writeBin` on, to read and write audio data using e.g. `snd_pcm_writei` which is part of the `alsa-lib` package.
>
>I don't think R supports user-defined connections, but probably
>writing readBin and writeBin equivalents specific to your library
>wouldn't be any harder than creating a connection.  For those, you
>will probably want to work with an "external pointer" (see Writing R
>Extensions). Rcpp probably has support for these if you're working in
>C++.

Thank you, yes I was following

https://stackoverflow.com/questions/59384221/proper-way-to-return-a-pointer-to-a-new-object-from-an-rcpp-function

which uses XPtr.

I'll forget about making a connection, if it is not supported.

I had this idea that I would be able to use the same code for writing to a file as to an audio device, but I can create my own class for that.

Frederick

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: defining r audio connections

Martin Morgan-4
In reply to this post by Duncan Murdoch-2
The public connection API is defined in

https://github.com/wch/r-source/blob/trunk/src/include/R_ext/Connections.h

I'm not sure of a good pedagogic example; people who want to write their own connections usually want to do so for complicated reasons!

This is my own abandoned attempt https://github.com/mtmorgan/socketeer/blob/b0a1448191fe5f79a3f09d1f939e1e235a22cf11/src/connection.c#L169-L192 where connection_local_client() is called from R and _connection_local() creates and populates the appropriate structure. Probably I have done things totally wrong (e.g., by not checking the version of the API, as advised in the header file!)

Martin Morgan

On 5/6/20, 2:26 PM, "R-devel on behalf of Duncan Murdoch" <[hidden email] on behalf of [hidden email]> wrote:

    On 06/05/2020 1:09 p.m., [hidden email] wrote:
    > Dear R Devel,
    >
    > Since Linux moved away from using a file-system interface for audio, I think it is necessary to write special libraries to interface with audio hardware from various languages on Linux.
    >
    > In R, it seems like the appropriate datatype for a `snd_pcm_t` handle pointing to an open ALSA source or sink would be a "connection". Connection types are already defined in R for "file", "url", "pipe", "fifo", "socketConnection", etc.
    >
    > Is there a tutorial or an example package where a new type of connection is defined, so that I can see how to do this properly in a package?
    >
    > I can see from the R source that, for example, `do_gzfile` is defined in `connections.c` and referenced in `names.c`. However, I thought I should ask here first in case there is a better place to start, than trying to copy this code.
    >
    > I only want an object that I can use `readBin` and `writeBin` on, to read and write audio data using e.g. `snd_pcm_writei` which is part of the `alsa-lib` package.

    I don't think R supports user-defined connections, but probably writing
    readBin and writeBin equivalents specific to your library wouldn't be
    any harder than creating a connection.  For those, you will probably
    want to work with an "external pointer" (see Writing R Extensions).
    Rcpp probably has support for these if you're working in C++.

    Duncan Murdoch

    ______________________________________________
    [hidden email] mailing list
    https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: defining r audio connections

Gábor Csárdi
AFAIK that API is not allowed on CRAN. It triggers a NOTE or a
WARNING, and your package will not be published.

Gabor

On Wed, May 6, 2020 at 9:04 PM Martin Morgan <[hidden email]> wrote:

>
> The public connection API is defined in
>
> https://github.com/wch/r-source/blob/trunk/src/include/R_ext/Connections.h
>
> I'm not sure of a good pedagogic example; people who want to write their own connections usually want to do so for complicated reasons!
>
> This is my own abandoned attempt https://github.com/mtmorgan/socketeer/blob/b0a1448191fe5f79a3f09d1f939e1e235a22cf11/src/connection.c#L169-L192 where connection_local_client() is called from R and _connection_local() creates and populates the appropriate structure. Probably I have done things totally wrong (e.g., by not checking the version of the API, as advised in the header file!)
>
> Martin Morgan
>
> On 5/6/20, 2:26 PM, "R-devel on behalf of Duncan Murdoch" <[hidden email] on behalf of [hidden email]> wrote:
>
>     On 06/05/2020 1:09 p.m., [hidden email] wrote:
>     > Dear R Devel,
>     >
>     > Since Linux moved away from using a file-system interface for audio, I think it is necessary to write special libraries to interface with audio hardware from various languages on Linux.
>     >
>     > In R, it seems like the appropriate datatype for a `snd_pcm_t` handle pointing to an open ALSA source or sink would be a "connection". Connection types are already defined in R for "file", "url", "pipe", "fifo", "socketConnection", etc.
>     >
>     > Is there a tutorial or an example package where a new type of connection is defined, so that I can see how to do this properly in a package?
>     >
>     > I can see from the R source that, for example, `do_gzfile` is defined in `connections.c` and referenced in `names.c`. However, I thought I should ask here first in case there is a better place to start, than trying to copy this code.
>     >
>     > I only want an object that I can use `readBin` and `writeBin` on, to read and write audio data using e.g. `snd_pcm_writei` which is part of the `alsa-lib` package.
>
>     I don't think R supports user-defined connections, but probably writing
>     readBin and writeBin equivalents specific to your library wouldn't be
>     any harder than creating a connection.  For those, you will probably
>     want to work with an "external pointer" (see Writing R Extensions).
>     Rcpp probably has support for these if you're working in C++.
>
>     Duncan Murdoch
>
>     ______________________________________________
>     [hidden email] mailing list
>     https://stat.ethz.ch/mailman/listinfo/r-devel
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: defining r audio connections

Martin Morgan-4
yep, you're right, after some initial clean-up and running with or without --as-cran R CMD check gives a NOTE

  *  checking compiled code
  File ‘socketeer/libs/socketeer.so’:
    Found non-API calls to R: ‘R_GetConnection’,
       ‘R_new_custom_connection’
   
  Compiled code should not call non-API entry points in R.
   
  See 'Writing portable packages' in the 'Writing R Extensions' manual.

Connections in general seem more useful than ad-hoc functions, though perhaps for Frederick's use case Duncan's suggestion is sufficient. For non-CRAN packages I personally would implement a connection.

(I mistakenly thought this was a more specialized mailing list; I wouldn't have posted to R-devel on this topic otherwise)

Martin Morgan

On 5/6/20, 4:12 PM, "Gábor Csárdi" <[hidden email]> wrote:

    AFAIK that API is not allowed on CRAN. It triggers a NOTE or a
    WARNING, and your package will not be published.

    Gabor

    On Wed, May 6, 2020 at 9:04 PM Martin Morgan <[hidden email]> wrote:
    >
    > The public connection API is defined in
    >
    > https://github.com/wch/r-source/blob/trunk/src/include/R_ext/Connections.h
    >
    > I'm not sure of a good pedagogic example; people who want to write their own connections usually want to do so for complicated reasons!
    >
    > This is my own abandoned attempt https://github.com/mtmorgan/socketeer/blob/b0a1448191fe5f79a3f09d1f939e1e235a22cf11/src/connection.c#L169-L192 where connection_local_client() is called from R and _connection_local() creates and populates the appropriate structure. Probably I have done things totally wrong (e.g., by not checking the version of the API, as advised in the header file!)
    >
    > Martin Morgan
    >
    > On 5/6/20, 2:26 PM, "R-devel on behalf of Duncan Murdoch" <[hidden email] on behalf of [hidden email]> wrote:
    >
    >     On 06/05/2020 1:09 p.m., [hidden email] wrote:
    >     > Dear R Devel,
    >     >
    >     > Since Linux moved away from using a file-system interface for audio, I think it is necessary to write special libraries to interface with audio hardware from various languages on Linux.
    >     >
    >     > In R, it seems like the appropriate datatype for a `snd_pcm_t` handle pointing to an open ALSA source or sink would be a "connection". Connection types are already defined in R for "file", "url", "pipe", "fifo", "socketConnection", etc.
    >     >
    >     > Is there a tutorial or an example package where a new type of connection is defined, so that I can see how to do this properly in a package?
    >     >
    >     > I can see from the R source that, for example, `do_gzfile` is defined in `connections.c` and referenced in `names.c`. However, I thought I should ask here first in case there is a better place to start, than trying to copy this code.
    >     >
    >     > I only want an object that I can use `readBin` and `writeBin` on, to read and write audio data using e.g. `snd_pcm_writei` which is part of the `alsa-lib` package.
    >
    >     I don't think R supports user-defined connections, but probably writing
    >     readBin and writeBin equivalents specific to your library wouldn't be
    >     any harder than creating a connection.  For those, you will probably
    >     want to work with an "external pointer" (see Writing R Extensions).
    >     Rcpp probably has support for these if you're working in C++.
    >
    >     Duncan Murdoch
    >
    >     ______________________________________________
    >     [hidden email] mailing list
    >     https://stat.ethz.ch/mailman/listinfo/r-devel
    > ______________________________________________
    > [hidden email] mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: defining r audio connections

Henrik Bengtsson-5
What's the gist of the problem of making/having this part of the public
API? Is it security, is it stability, is it that the current API is under
construction, is it a worry about maintenance load for R Core, ...? Do we
know why?

It sounds like it's a feature that is  useful. I think we missed out on
some great enhancements in the past because of it not being part of the
public API.

/Henrik

On Wed, May 6, 2020, 16:26 Martin Morgan <[hidden email]> wrote:

> yep, you're right, after some initial clean-up and running with or without
> --as-cran R CMD check gives a NOTE
>
>   *  checking compiled code
>   File ‘socketeer/libs/socketeer.so’:
>     Found non-API calls to R: ‘R_GetConnection’,
>        ‘R_new_custom_connection’
>
>   Compiled code should not call non-API entry points in R.
>
>   See 'Writing portable packages' in the 'Writing R Extensions' manual.
>
> Connections in general seem more useful than ad-hoc functions, though
> perhaps for Frederick's use case Duncan's suggestion is sufficient. For
> non-CRAN packages I personally would implement a connection.
>
> (I mistakenly thought this was a more specialized mailing list; I wouldn't
> have posted to R-devel on this topic otherwise)
>
> Martin Morgan
>
> On 5/6/20, 4:12 PM, "Gábor Csárdi" <[hidden email]> wrote:
>
>     AFAIK that API is not allowed on CRAN. It triggers a NOTE or a
>     WARNING, and your package will not be published.
>
>     Gabor
>
>     On Wed, May 6, 2020 at 9:04 PM Martin Morgan <[hidden email]>
> wrote:
>     >
>     > The public connection API is defined in
>     >
>     >
> https://github.com/wch/r-source/blob/trunk/src/include/R_ext/Connections.h
>     >
>     > I'm not sure of a good pedagogic example; people who want to write
> their own connections usually want to do so for complicated reasons!
>     >
>     > This is my own abandoned attempt
> https://github.com/mtmorgan/socketeer/blob/b0a1448191fe5f79a3f09d1f939e1e235a22cf11/src/connection.c#L169-L192
> where connection_local_client() is called from R and _connection_local()
> creates and populates the appropriate structure. Probably I have done
> things totally wrong (e.g., by not checking the version of the API, as
> advised in the header file!)
>     >
>     > Martin Morgan
>     >
>     > On 5/6/20, 2:26 PM, "R-devel on behalf of Duncan Murdoch" <
> [hidden email] on behalf of [hidden email]>
> wrote:
>     >
>     >     On 06/05/2020 1:09 p.m., [hidden email] wrote:
>     >     > Dear R Devel,
>     >     >
>     >     > Since Linux moved away from using a file-system interface for
> audio, I think it is necessary to write special libraries to interface with
> audio hardware from various languages on Linux.
>     >     >
>     >     > In R, it seems like the appropriate datatype for a `snd_pcm_t`
> handle pointing to an open ALSA source or sink would be a "connection".
> Connection types are already defined in R for "file", "url", "pipe",
> "fifo", "socketConnection", etc.
>     >     >
>     >     > Is there a tutorial or an example package where a new type of
> connection is defined, so that I can see how to do this properly in a
> package?
>     >     >
>     >     > I can see from the R source that, for example, `do_gzfile` is
> defined in `connections.c` and referenced in `names.c`. However, I thought
> I should ask here first in case there is a better place to start, than
> trying to copy this code.
>     >     >
>     >     > I only want an object that I can use `readBin` and `writeBin`
> on, to read and write audio data using e.g. `snd_pcm_writei` which is part
> of the `alsa-lib` package.
>     >
>     >     I don't think R supports user-defined connections, but probably
> writing
>     >     readBin and writeBin equivalents specific to your library
> wouldn't be
>     >     any harder than creating a connection.  For those, you will
> probably
>     >     want to work with an "external pointer" (see Writing R
> Extensions).
>     >     Rcpp probably has support for these if you're working in C++.
>     >
>     >     Duncan Murdoch
>     >
>     >     ______________________________________________
>     >     [hidden email] mailing list
>     >     https://stat.ethz.ch/mailman/listinfo/r-devel
>     > ______________________________________________
>     > [hidden email] mailing list
>     > https://stat.ethz.ch/mailman/listinfo/r-devel
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: defining r audio connections

Jim Hester
https://github.com/jimhester/archive was not allowed on CRAN when I
submitted it 3 years ago due to this restriction.

Being able to write custom connections is a useful feature for a number of
applications, I would love this policy to be reconsidered.

On Wed, May 6, 2020 at 10:30 PM Henrik Bengtsson <[hidden email]>
wrote:

> What's the gist of the problem of making/having this part of the public
> API? Is it security, is it stability, is it that the current API is under
> construction, is it a worry about maintenance load for R Core, ...? Do we
> know why?
>
> It sounds like it's a feature that is  useful. I think we missed out on
> some great enhancements in the past because of it not being part of the
> public API.
>
> /Henrik
>
> On Wed, May 6, 2020, 16:26 Martin Morgan <[hidden email]> wrote:
>
> > yep, you're right, after some initial clean-up and running with or
> without
> > --as-cran R CMD check gives a NOTE
> >
> >   *  checking compiled code
> >   File ‘socketeer/libs/socketeer.so’:
> >     Found non-API calls to R: ‘R_GetConnection’,
> >        ‘R_new_custom_connection’
> >
> >   Compiled code should not call non-API entry points in R.
> >
> >   See 'Writing portable packages' in the 'Writing R Extensions' manual.
> >
> > Connections in general seem more useful than ad-hoc functions, though
> > perhaps for Frederick's use case Duncan's suggestion is sufficient. For
> > non-CRAN packages I personally would implement a connection.
> >
> > (I mistakenly thought this was a more specialized mailing list; I
> wouldn't
> > have posted to R-devel on this topic otherwise)
> >
> > Martin Morgan
> >
> > On 5/6/20, 4:12 PM, "Gábor Csárdi" <[hidden email]> wrote:
> >
> >     AFAIK that API is not allowed on CRAN. It triggers a NOTE or a
> >     WARNING, and your package will not be published.
> >
> >     Gabor
> >
> >     On Wed, May 6, 2020 at 9:04 PM Martin Morgan <
> [hidden email]>
> > wrote:
> >     >
> >     > The public connection API is defined in
> >     >
> >     >
> >
> https://github.com/wch/r-source/blob/trunk/src/include/R_ext/Connections.h
> >     >
> >     > I'm not sure of a good pedagogic example; people who want to write
> > their own connections usually want to do so for complicated reasons!
> >     >
> >     > This is my own abandoned attempt
> >
> https://github.com/mtmorgan/socketeer/blob/b0a1448191fe5f79a3f09d1f939e1e235a22cf11/src/connection.c#L169-L192
> > where connection_local_client() is called from R and _connection_local()
> > creates and populates the appropriate structure. Probably I have done
> > things totally wrong (e.g., by not checking the version of the API, as
> > advised in the header file!)
> >     >
> >     > Martin Morgan
> >     >
> >     > On 5/6/20, 2:26 PM, "R-devel on behalf of Duncan Murdoch" <
> > [hidden email] on behalf of [hidden email]>
> > wrote:
> >     >
> >     >     On 06/05/2020 1:09 p.m., [hidden email] wrote:
> >     >     > Dear R Devel,
> >     >     >
> >     >     > Since Linux moved away from using a file-system interface for
> > audio, I think it is necessary to write special libraries to interface
> with
> > audio hardware from various languages on Linux.
> >     >     >
> >     >     > In R, it seems like the appropriate datatype for a
> `snd_pcm_t`
> > handle pointing to an open ALSA source or sink would be a "connection".
> > Connection types are already defined in R for "file", "url", "pipe",
> > "fifo", "socketConnection", etc.
> >     >     >
> >     >     > Is there a tutorial or an example package where a new type of
> > connection is defined, so that I can see how to do this properly in a
> > package?
> >     >     >
> >     >     > I can see from the R source that, for example, `do_gzfile` is
> > defined in `connections.c` and referenced in `names.c`. However, I
> thought
> > I should ask here first in case there is a better place to start, than
> > trying to copy this code.
> >     >     >
> >     >     > I only want an object that I can use `readBin` and `writeBin`
> > on, to read and write audio data using e.g. `snd_pcm_writei` which is
> part
> > of the `alsa-lib` package.
> >     >
> >     >     I don't think R supports user-defined connections, but probably
> > writing
> >     >     readBin and writeBin equivalents specific to your library
> > wouldn't be
> >     >     any harder than creating a connection.  For those, you will
> > probably
> >     >     want to work with an "external pointer" (see Writing R
> > Extensions).
> >     >     Rcpp probably has support for these if you're working in C++.
> >     >
> >     >     Duncan Murdoch
> >     >
> >     >     ______________________________________________
> >     >     [hidden email] mailing list
> >     >     https://stat.ethz.ch/mailman/listinfo/r-devel
> >     > ______________________________________________
> >     > [hidden email] mailing list
> >     > https://stat.ethz.ch/mailman/listinfo/r-devel
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: defining r audio connections

Simon Urbanek
The custom connections API was specifically introduced to allow packages to create custom connections back in 2013. Its sole purpose is to allow package authors to create new connections outside of base R, so I don't see why packages using it shouldn't be allowed on CRAN. However, it is solely at CRAN's discretion to decide what gets published, so it may be worth raising it with the team, ask for the reasons and what it would take for them to accept packages using that API.

Cheers,
Simon


> On 8/05/2020, at 1:02 AM, Jim Hester <[hidden email]> wrote:
>
> https://github.com/jimhester/archive was not allowed on CRAN when I
> submitted it 3 years ago due to this restriction.
>
> Being able to write custom connections is a useful feature for a number of
> applications, I would love this policy to be reconsidered.
>
> On Wed, May 6, 2020 at 10:30 PM Henrik Bengtsson <[hidden email]>
> wrote:
>
>> What's the gist of the problem of making/having this part of the public
>> API? Is it security, is it stability, is it that the current API is under
>> construction, is it a worry about maintenance load for R Core, ...? Do we
>> know why?
>>
>> It sounds like it's a feature that is  useful. I think we missed out on
>> some great enhancements in the past because of it not being part of the
>> public API.
>>
>> /Henrik
>>
>> On Wed, May 6, 2020, 16:26 Martin Morgan <[hidden email]> wrote:
>>
>>> yep, you're right, after some initial clean-up and running with or
>> without
>>> --as-cran R CMD check gives a NOTE
>>>
>>>  *  checking compiled code
>>>  File ‘socketeer/libs/socketeer.so’:
>>>    Found non-API calls to R: ‘R_GetConnection’,
>>>       ‘R_new_custom_connection’
>>>
>>>  Compiled code should not call non-API entry points in R.
>>>
>>>  See 'Writing portable packages' in the 'Writing R Extensions' manual.
>>>
>>> Connections in general seem more useful than ad-hoc functions, though
>>> perhaps for Frederick's use case Duncan's suggestion is sufficient. For
>>> non-CRAN packages I personally would implement a connection.
>>>
>>> (I mistakenly thought this was a more specialized mailing list; I
>> wouldn't
>>> have posted to R-devel on this topic otherwise)
>>>
>>> Martin Morgan
>>>
>>> On 5/6/20, 4:12 PM, "Gábor Csárdi" <[hidden email]> wrote:
>>>
>>>    AFAIK that API is not allowed on CRAN. It triggers a NOTE or a
>>>    WARNING, and your package will not be published.
>>>
>>>    Gabor
>>>
>>>    On Wed, May 6, 2020 at 9:04 PM Martin Morgan <
>> [hidden email]>
>>> wrote:
>>>>
>>>> The public connection API is defined in
>>>>
>>>>
>>>
>> https://github.com/wch/r-source/blob/trunk/src/include/R_ext/Connections.h
>>>>
>>>> I'm not sure of a good pedagogic example; people who want to write
>>> their own connections usually want to do so for complicated reasons!
>>>>
>>>> This is my own abandoned attempt
>>>
>> https://github.com/mtmorgan/socketeer/blob/b0a1448191fe5f79a3f09d1f939e1e235a22cf11/src/connection.c#L169-L192
>>> where connection_local_client() is called from R and _connection_local()
>>> creates and populates the appropriate structure. Probably I have done
>>> things totally wrong (e.g., by not checking the version of the API, as
>>> advised in the header file!)
>>>>
>>>> Martin Morgan
>>>>
>>>> On 5/6/20, 2:26 PM, "R-devel on behalf of Duncan Murdoch" <
>>> [hidden email] on behalf of [hidden email]>
>>> wrote:
>>>>
>>>>    On 06/05/2020 1:09 p.m., [hidden email] wrote:
>>>>> Dear R Devel,
>>>>>
>>>>> Since Linux moved away from using a file-system interface for
>>> audio, I think it is necessary to write special libraries to interface
>> with
>>> audio hardware from various languages on Linux.
>>>>>
>>>>> In R, it seems like the appropriate datatype for a
>> `snd_pcm_t`
>>> handle pointing to an open ALSA source or sink would be a "connection".
>>> Connection types are already defined in R for "file", "url", "pipe",
>>> "fifo", "socketConnection", etc.
>>>>>
>>>>> Is there a tutorial or an example package where a new type of
>>> connection is defined, so that I can see how to do this properly in a
>>> package?
>>>>>
>>>>> I can see from the R source that, for example, `do_gzfile` is
>>> defined in `connections.c` and referenced in `names.c`. However, I
>> thought
>>> I should ask here first in case there is a better place to start, than
>>> trying to copy this code.
>>>>>
>>>>> I only want an object that I can use `readBin` and `writeBin`
>>> on, to read and write audio data using e.g. `snd_pcm_writei` which is
>> part
>>> of the `alsa-lib` package.
>>>>
>>>>    I don't think R supports user-defined connections, but probably
>>> writing
>>>>    readBin and writeBin equivalents specific to your library
>>> wouldn't be
>>>>    any harder than creating a connection.  For those, you will
>>> probably
>>>>    want to work with an "external pointer" (see Writing R
>>> Extensions).
>>>>    Rcpp probably has support for these if you're working in C++.
>>>>
>>>>    Duncan Murdoch
>>>>
>>>>    ______________________________________________
>>>>    [hidden email] mailing list
>>>>    https://stat.ethz.ch/mailman/listinfo/r-devel
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>        [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel