Sound support: ALSA or OSS in NDK?
961 views
Skip to first unread message
Datoh
Oct 8, 2009, 11:13:55 AM10/8/09
to android-ndk
Hi,
Does the NDK (1.6) allows to use ALSA or OSS sound library?
Regards,
Datoh.
Does the NDK (1.6) allows to use ALSA or OSS sound library?
Regards,
Datoh.
niko20
Oct 8, 2009, 1:07:46 PM10/8/09
to android-ndk
Hi,
The NDK doesn't have any sound support yet.
-niko
The NDK doesn't have any sound support yet.
-niko
HeHe
Oct 10, 2009, 2:53:53 PM10/10/09
to android-ndk
is it an official answer from Android team that Android NDK does not
support ALSA and OSS api?
what is officially recommended api to program audio and video devices
in native C?
support ALSA and OSS api?
what is officially recommended api to program audio and video devices
in native C?
Doug Schaefer
Oct 10, 2009, 11:45:50 PM10/10/09
to andro...@googlegroups.com
Technical too. There's no header files or libs in the NDK for ALSA or OSS. I'm not sure why you are asking this question without looking at the NDK first.
HeHe
Oct 11, 2009, 2:02:50 AM10/11/09
to android-ndk
thanks for the reply.
have you ever looked into NDK directories?
there is a "soundcard.h" included with NDK, which defines
"OPEN_SOUND_SYSTEM".
i am not sure why the header file and the macro are there if OSS is
not supported.
have you ever looked into NDK directories?
there is a "soundcard.h" included with NDK, which defines
"OPEN_SOUND_SYSTEM".
i am not sure why the header file and the macro are there if OSS is
not supported.
David Turner
Oct 12, 2009, 5:01:58 PM10/12/09
to andro...@googlegroups.com
On Sat, Oct 10, 2009 at 11:53 AM, HeHe <cnm...@gmail.com> wrote:
is it an official answer from Android team that Android NDK does not
support ALSA and OSS api?
Yes, absolutely
what is officially recommended api to program audio and video devices
in native C?
There is none at the moment (except OpenGL ES headers if you target 3D rendering on Donut)
David Turner
Oct 12, 2009, 5:02:35 PM10/12/09
to andro...@googlegroups.com
On Sat, Oct 10, 2009 at 11:02 PM, HeHe <cnm...@gmail.com> wrote:
thanks for the reply.
have you ever looked into NDK directories?
there is a "soundcard.h" included with NDK, which defines
"OPEN_SOUND_SYSTEM".
i am not sure why the header file and the macro are there if OSS is
not supported.
this is a kernel header, the definitions here do not relate to the capabilities of the kernel running on your device,
or the corresponding user-level APIs that can be used from native code.
Peter Kirn
Oct 27, 2009, 12:21:21 AM10/27/09
to android-ndk
David, rather than re-post this since it's been asked various times,
I'll pick up this most recent thread to ask the question in a
different way... imagine, for a moment, you're an audio developer and
you care about Android, and you're interested in doing live sound
synthesis and signal processing. This kind of development is of course
the domain of a small number of programmers, relatively, but it can
have wide implications and use cases out in the market.
Obviously, downloading the NDK as a preview would be something you'd
be likely to do, and I know there aren't capabilities there - or in
the Java APIs - yet. So, then, what's your next step as a developer,
even to be prepared for what may be coming down the road? There are
drop-in solutions that work with ALSA right now on nearly-identical
hardware, like Pure Data which I've run on the chipset that's in my
G1, but accessing ALSA is off-limits on Android to developers. I'm
aware of the issues with ALSA, but that means that on other platforms
you can run these native solutions, and on Android you can't.
Unless I'm missing something, there really isn't any workable way to
do any DSP or synthesis, not in the NDK and not outside the NDK.
Let me just clarify:
* part of the reason you can't depend on ALSA is because ALSA modules
may not be implemented by all hardware?
* is it worth it at this point even trying to build NDK DSP code
(minus any audio output) to see if it works?
* is it at least theoretically conceivable that developers who know
what they're doing could write DSP operations with the NDK and use a
Java callback on the byte output of that to route sound out?
I'm aware of the issues of being overly-reliant on native code, and
the many potential pitfalls of ALSA, so this isn't a criticism of
Android or the NDK. I just want to make sure that my current
understanding of the state of affairs is correct. That is, we have the
negative definition (there's no audio support currently in NDK), but I
haven't seen a lucid explanation of how people interested in audio
should approach the platform right now, today.
Peter Kirn
I'll pick up this most recent thread to ask the question in a
different way... imagine, for a moment, you're an audio developer and
you care about Android, and you're interested in doing live sound
synthesis and signal processing. This kind of development is of course
the domain of a small number of programmers, relatively, but it can
have wide implications and use cases out in the market.
Obviously, downloading the NDK as a preview would be something you'd
be likely to do, and I know there aren't capabilities there - or in
the Java APIs - yet. So, then, what's your next step as a developer,
even to be prepared for what may be coming down the road? There are
drop-in solutions that work with ALSA right now on nearly-identical
hardware, like Pure Data which I've run on the chipset that's in my
G1, but accessing ALSA is off-limits on Android to developers. I'm
aware of the issues with ALSA, but that means that on other platforms
you can run these native solutions, and on Android you can't.
Unless I'm missing something, there really isn't any workable way to
do any DSP or synthesis, not in the NDK and not outside the NDK.
Let me just clarify:
* part of the reason you can't depend on ALSA is because ALSA modules
may not be implemented by all hardware?
* is it worth it at this point even trying to build NDK DSP code
(minus any audio output) to see if it works?
* is it at least theoretically conceivable that developers who know
what they're doing could write DSP operations with the NDK and use a
Java callback on the byte output of that to route sound out?
I'm aware of the issues of being overly-reliant on native code, and
the many potential pitfalls of ALSA, so this isn't a criticism of
Android or the NDK. I just want to make sure that my current
understanding of the state of affairs is correct. That is, we have the
negative definition (there's no audio support currently in NDK), but I
haven't seen a lucid explanation of how people interested in audio
should approach the platform right now, today.
Peter Kirn
niko20
Oct 27, 2009, 11:30:12 AM10/27/09
to android-ndk
Hi Peter,
I think it is definitely still worthwhile to code your DSP algos in
the NDK and experiment with them. You could pass in a buffer to Native
code and DSP it, then pass it back to play it, etc.
I've already done this in my app that is on the market, I have
resampling code that is written in native code - I pass in my audio
data and resample it, then pass it back. It works fine.
However, for "real time" you are not going to have as much success
because through my testing I've found that any audio done on the
current Java API's has at least a 100ms buffer delay in it at
minimum.
So until we can get better NDK access to the actual sound output, we
have high latency which isn't good for any real time stuff. You could
still of course generate waveforms, a 100ms buffer isn't going to kill
you there, but if you want to be able to react to user input in a real
time way (like they push a piano key and it plays), the latency will
ruin that type of app. You can still make a sequencing app though
since you only have to deal with the latency til the buffer is full,
so that kind of delay isn't as big of a deal.
I think there is plenty of room to do DSP - you definitely want to try
to used fixed point as much as possible for max speed though. It's
just you won't be writing "I am TPain" anytime soon, not with the
latency issue. But other types of apps are still possible.
-niko
I think it is definitely still worthwhile to code your DSP algos in
the NDK and experiment with them. You could pass in a buffer to Native
code and DSP it, then pass it back to play it, etc.
I've already done this in my app that is on the market, I have
resampling code that is written in native code - I pass in my audio
data and resample it, then pass it back. It works fine.
However, for "real time" you are not going to have as much success
because through my testing I've found that any audio done on the
current Java API's has at least a 100ms buffer delay in it at
minimum.
So until we can get better NDK access to the actual sound output, we
have high latency which isn't good for any real time stuff. You could
still of course generate waveforms, a 100ms buffer isn't going to kill
you there, but if you want to be able to react to user input in a real
time way (like they push a piano key and it plays), the latency will
ruin that type of app. You can still make a sequencing app though
since you only have to deal with the latency til the buffer is full,
so that kind of delay isn't as big of a deal.
I think there is plenty of room to do DSP - you definitely want to try
to used fixed point as much as possible for max speed though. It's
just you won't be writing "I am TPain" anytime soon, not with the
latency issue. But other types of apps are still possible.
-niko
David Turner
Oct 28, 2009, 12:55:47 AM10/28/09
to andro...@googlegroups.com
On Mon, Oct 26, 2009 at 9:21 PM, Peter Kirn <pete...@gmail.com> wrote:
David, rather than re-post this since it's been asked various times,
I'll pick up this most recent thread to ask the question in a
different way... imagine, for a moment, you're an audio developer and
you care about Android, and you're interested in doing live sound
synthesis and signal processing. This kind of development is of course
the domain of a small number of programmers, relatively, but it can
have wide implications and use cases out in the market.
Obviously, downloading the NDK as a preview would be something you'd
be likely to do, and I know there aren't capabilities there - or in
the Java APIs - yet. So, then, what's your next step as a developer,
even to be prepared for what may be coming down the road? There are
drop-in solutions that work with ALSA right now on nearly-identical
hardware, like Pure Data which I've run on the chipset that's in my
G1, but accessing ALSA is off-limits on Android to developers. I'm
aware of the issues with ALSA, but that means that on other platforms
you can run these native solutions, and on Android you can't.
Unless I'm missing something, there really isn't any workable way to
do any DSP or synthesis, not in the NDK and not outside the NDK.
Let me just clarify:
* part of the reason you can't depend on ALSA is because ALSA modules
may not be implemented by all hardware?
There is absolutely no guarantee that the kernel available on a production Android device
would use ALSA (it could be OSS, or whatever hardware-specific hack required by heavily
customized hardware).
* is it worth it at this point even trying to build NDK DSP code
(minus any audio output) to see if it works?
Feel free to use the NDK to write DSP code that acts on sound sample buffers. You
will have to get/send the buffers from Java at this point though. Direct access to a
real audio API is not available yet.
* is it at least theoretically conceivable that developers who know
what they're doing could write DSP operations with the NDK and use a
Java callback on the byte output of that to route sound out?
Yes; and some already do as far as I know, but I don't have any details to share,
unfortunately.
Peter Kirn
Oct 28, 2009, 10:57:01 AM10/28/09
to android-ndk
Thanks, David. That makes sense.
I suppose the potential lack of ALSA could be a reason to choose OSS
as a lowest common denominator -- anything with ALSA support should
(theoretically) then support OSS emulation, though again there may be
fewer guarantees.
And yes, in the meantime, I'll try the Java > NDK > Java route.
Peter
On Oct 28, 12:55 am, David Turner <di...@android.com> wrote:
I suppose the potential lack of ALSA could be a reason to choose OSS
as a lowest common denominator -- anything with ALSA support should
(theoretically) then support OSS emulation, though again there may be
fewer guarantees.
And yes, in the meantime, I'll try the Java > NDK > Java route.
Peter
On Oct 28, 12:55 am, David Turner <di...@android.com> wrote:
Kevin
Nov 20, 2009, 7:12:14 PM11/20/09
to android-ndk
I am pushing for better audio support in the NDK, see Android Bug
3434.
http://code.google.com/p/android/issues/detail?id=3434
Kevin
On 28 oct, 15:57, Peter Kirn <peterk...@gmail.com> wrote:
> Thanks, David. That makes sense.
>
> I suppose the potential lack of ALSA could be a reason to choose OSS
> as a lowest common denominator -- anything with ALSA support should
> (theoretically) then support OSS emulation, though again there may be
> fewer guarantees.
>
> And yes, in the meantime, I'll try the Java >NDK> Java route.
>
> Peter
>
> On Oct 28, 12:55 am, David Turner <di...@android.com> wrote:
>
>
>
> > On Mon, Oct 26, 2009 at 9:21 PM, Peter Kirn <peterk...@gmail.com> wrote:
>
> > > David, rather than re-post this since it's been asked various times,
> > > I'll pick up this most recent thread to ask the question in a
> > > different way... imagine, for a moment, you're anaudiodeveloper and
>
> > Feel free to use theNDKto write DSP code that acts on sound sample
>
> > > > > > > > > Regards,
> > > > > > > > > Datoh.- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -
3434.
http://code.google.com/p/android/issues/detail?id=3434
Kevin
On 28 oct, 15:57, Peter Kirn <peterk...@gmail.com> wrote:
> Thanks, David. That makes sense.
>
> I suppose the potential lack of ALSA could be a reason to choose OSS
> as a lowest common denominator -- anything with ALSA support should
> (theoretically) then support OSS emulation, though again there may be
> fewer guarantees.
>
> And yes, in the meantime, I'll try the Java >NDK> Java route.
>
> Peter
>
> On Oct 28, 12:55 am, David Turner <di...@android.com> wrote:
>
>
>
> > On Mon, Oct 26, 2009 at 9:21 PM, Peter Kirn <peterk...@gmail.com> wrote:
>
> > > David, rather than re-post this since it's been asked various times,
> > > I'll pick up this most recent thread to ask the question in a
> > > you care about Android, and you're interested in doing live sound
> > > synthesis and signal processing. This kind of development is of course
> > > the domain of a small number of programmers, relatively, but it can
> > > have wide implications and use cases out in the market.
>
> > > Obviously, downloading theNDKas a preview would be something you'd
> > > synthesis and signal processing. This kind of development is of course
> > > the domain of a small number of programmers, relatively, but it can
> > > have wide implications and use cases out in the market.
>
> > > be likely to do, and I know there aren't capabilities there - or in
> > > the Java APIs - yet. So, then, what's your next step as a developer,
> > > even to be prepared for what may be coming down the road? There are
> > > drop-in solutions that work with ALSA right now on nearly-identical
> > > hardware, like Pure Data which I've run on the chipset that's in my
> > > G1, but accessing ALSA is off-limits on Android to developers. I'm
> > > aware of the issues with ALSA, but that means that on other platforms
> > > you can run these native solutions, and on Android you can't.
>
> > > Unless I'm missing something, there really isn't any workable way to
> > > do any DSP or synthesis, not in theNDKand not outside theNDK.
>
> > > Let me just clarify:
> > > * part of the reason you can't depend on ALSA is because ALSA modules
> > > may not be implemented by all hardware?
>
> > There is absolutely no guarantee that the kernel available on a production
> > Android device
> > would use ALSA (it could be OSS, or whatever hardware-specific hack required
> > by heavily
> > customized hardware).
>
> > > * is it worth it at this point even trying to buildNDKDSP code
> > > (minus anyaudiooutput) to see if it works?
> > > the Java APIs - yet. So, then, what's your next step as a developer,
> > > even to be prepared for what may be coming down the road? There are
> > > drop-in solutions that work with ALSA right now on nearly-identical
> > > hardware, like Pure Data which I've run on the chipset that's in my
> > > G1, but accessing ALSA is off-limits on Android to developers. I'm
> > > aware of the issues with ALSA, but that means that on other platforms
> > > you can run these native solutions, and on Android you can't.
>
> > > Unless I'm missing something, there really isn't any workable way to
> > > do any DSP or synthesis, not in theNDKand not outside theNDK.
>
> > > Let me just clarify:
> > > * part of the reason you can't depend on ALSA is because ALSA modules
> > > may not be implemented by all hardware?
>
> > There is absolutely no guarantee that the kernel available on a production
> > Android device
> > would use ALSA (it could be OSS, or whatever hardware-specific hack required
> > by heavily
> > customized hardware).
>
> > > * is it worth it at this point even trying to buildNDKDSP code
>
> > Feel free to use theNDKto write DSP code that acts on sound sample
> > buffers. You
> > will have to get/send the buffers from Java at this point though. Direct
> > access to a
> > realaudioAPI is not available yet.
> > will have to get/send the buffers from Java at this point though. Direct
> > access to a
>
> > > * is it at least theoretically conceivable that developers who know
> > > what they're doing could write DSP operations with theNDKand use a
> > > * is it at least theoretically conceivable that developers who know
> > > Java callback on the byte output of that to route sound out?
>
> > Yes; and some already do as far as I know, but I don't have any details to
> > share,
> > unfortunately.
>
> > > I'm aware of the issues of being overly-reliant on native code, and
> > > the many potential pitfalls of ALSA, so this isn't a criticism of
> > > Android or theNDK. I just want to make sure that my current
>
> > Yes; and some already do as far as I know, but I don't have any details to
> > share,
> > unfortunately.
>
> > > I'm aware of the issues of being overly-reliant on native code, and
> > > the many potential pitfalls of ALSA, so this isn't a criticism of
> > > understanding of the state of affairs is correct. That is, we have the
> > > negative definition (there's noaudiosupport currently inNDK), but I
> > > haven't seen a lucid explanation of how people interested inaudio
> > > should approach the platform right now, today.
>
> > > Peter Kirn
>
> > > On Oct 12, 5:02 pm, David Turner <di...@android.com> wrote:
> > > > On Sat, Oct 10, 2009 at 11:02 PM, HeHe <cnm...@gmail.com> wrote:
>
> > > > > thanks for the reply.
>
> > > > > have you ever looked intoNDKdirectories?
>
> > > > > there is a "soundcard.h" included withNDK, which defines
> > > should approach the platform right now, today.
>
> > > Peter Kirn
>
> > > On Oct 12, 5:02 pm, David Turner <di...@android.com> wrote:
> > > > On Sat, Oct 10, 2009 at 11:02 PM, HeHe <cnm...@gmail.com> wrote:
>
> > > > > thanks for the reply.
>
> > > > > have you ever looked intoNDKdirectories?
>
> > > > > "OPEN_SOUND_SYSTEM".
>
> > > > > i am not sure why the header file and the macro are there if OSS is
> > > > > not supported.
>
> > > > this is a kernel header, the definitions here do not relate to the
> > > > capabilities of the kernel running on your device,
> > > > or the corresponding user-level APIs that can be used from native code.
>
> > > > > On Oct 10, 8:45 pm, Doug Schaefer <cdtd...@gmail.com> wrote:
> > > > > > Technical too. There's no header files or libs in theNDKfor ALSA or
>
> > > > > i am not sure why the header file and the macro are there if OSS is
> > > > > not supported.
>
> > > > this is a kernel header, the definitions here do not relate to the
> > > > capabilities of the kernel running on your device,
> > > > or the corresponding user-level APIs that can be used from native code.
>
> > > > > On Oct 10, 8:45 pm, Doug Schaefer <cdtd...@gmail.com> wrote:
> > > > > OSS.
> > > > > > I'm not sure why you are asking this question without looking at the
> > >NDK
> > > > > > first.
>
> > > > > > On Sat, Oct 10, 2009 at 2:53 PM, HeHe <cnm...@gmail.com> wrote:
>
> > > > > > > is it an official answer from Android team that AndroidNDKdoes
> > > not
> > > > > > > support ALSA and OSS api?
>
> > > > > > > what is officially recommended api to programaudioand video
> > > > > > I'm not sure why you are asking this question without looking at the
> > >NDK
> > > > > > first.
>
> > > > > > On Sat, Oct 10, 2009 at 2:53 PM, HeHe <cnm...@gmail.com> wrote:
>
> > > > > > > is it an official answer from Android team that AndroidNDKdoes
> > > not
> > > > > > > support ALSA and OSS api?
>
> > > devices
> > > > > > > in native C?
>
> > > > > > > On Oct 8, 10:07 am, niko20 <nikolatesl...@yahoo.com> wrote:
> > > > > > > > Hi,
>
> > > > > > > > TheNDKdoesn't have any sound support yet.
> > > > > > > in native C?
>
> > > > > > > On Oct 8, 10:07 am, niko20 <nikolatesl...@yahoo.com> wrote:
> > > > > > > > Hi,
>
>
> > > > > > > > -niko
>
> > > > > > > > On Oct 8, 10:13 am, Datoh <dato...@gmail.com> wrote:
>
> > > > > > > > > Hi,
>
> > > > > > > > > Does theNDK(1.6) allows to use ALSA or OSS sound library?
> > > > > > > > -niko
>
> > > > > > > > On Oct 8, 10:13 am, Datoh <dato...@gmail.com> wrote:
>
> > > > > > > > > Hi,
>
>
> > > > > > > > > Regards,
> > > > > > > > > Datoh.- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -
Reply all
Reply to author
Forward
0 new messages