29 May
2009
29 May
'09
7 p.m.
Hi All,
i'm seeking an advise on the preferred way to support a dedicated DSP
chip under ALSA.
The system is an embedded system constructed on a dual core chip - one
core is ARM vanlia and the other is a dedicated DSP core.
The DSP core is capable of both playing both encoded streams (mp3, wma,
various voice coders) and of course PCM streams.
the codec (a2d, d2a) are connected to DSP.
I looking for an elegant design to hide the DSP under the ALSA sysem and
I have several ideas and would like to get your advise:
1. use LADSPA to make the DSP look as a plug-in for both control
and data - what I don't know is if LADSPA forces me to return data to
the ALSA for sending it to the kernel drivers
2. use the LADSPA to make the DSP control only and make another
kernel driver for the audio data pass - is it possible? There can be a
sync problem between the commands and the time the data will arrive?
Will this support JACKD ?
I'm open to other suggestions as well,
Thanks in advance
Ziv
______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using MessageLabs Email
Security System.
_____________________________________________________________________
30 May
30 May
8:28 a.m.
Ziv Haziz wrote:
i'm seeking an advise on the preferred way to
support a dedicated DSP
chip under ALSA.
Unfortunately ALSA is pretty bad on abstracting anything else except PCM
streaming and MIDI.
For ages I have been concerned about how to support hardware accelerated
(DSP) 3D audio. OpenSL ES seems to be the only option at the moment.
The DSP core is capable of both playing both encoded
streams (mp3, wma,
various voice coders) and of course PCM streams.
the codec (a2d, d2a) are connected to DSP.
I think you might have better luck by using OpenMAX[1], it has been
designed for this kind of use.
- Jussi
[1] http://www.khronos.org/openmax/
9:59 a.m.
Would this be the reason why Saffire's onboard DSP effects can't be
supported (via ffado)?
3:49 p.m.
i'm seeking an advise on the preferred way to
support a dedicated DSP
chip under ALSA.
Unfortunately ALSA is pretty bad on abstracting
anything else except
PCM
streaming and MIDI.
As far as I have looked inside the ALSA API there is support for
"special" format and GSM format so ALSA can pass encoded data.
Also since this is an embedded system I can control exactly the DSP
peripherals connected to the system so I may "trick" the system.
For ages I have been concerned about how to support
hardware
accelerated
(DSP) 3D audio. OpenSL ES seems to be the only option
at the moment.
The DSP core is capable of both playing both encoded
streams (mp3,
wma,
various voice coders) and of course PCM streams.
the codec (a2d, d2a) are connected to DSP.
I think you might have better luck by using
OpenMAX[1], it has been
designed for this kind of use.
The problem with OpenMAX is that most of the common players (at least
the ones I looked into mplayer and mpg123) doesn't support them
natively.
If I will use sample format "special" will the alsa know not to try and
do manipulation over it? (resampling, volume, etc...)
And last question - in the LADSP interface file I have seen that I can
be a control plug-in - this means that ALSA will pass all control signal
to me including rate, volume, open close and other?
Thanks,
Ziv
______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using
MessageLabs Email Security System.
_____________________________________________________________________
______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using MessageLabs Email
Security System.
_____________________________________________________________________
6:37 p.m.
Ziv Haziz wrote:
The problem with OpenMAX is that most of the common
players (at least
the ones I looked into mplayer and mpg123) doesn't support them
natively.
I don't see much point in that anyway since, AFAIK, those players don't
support offloading decoding to DSP anyway. If the support is added, then
it should be fairly trivial to use some other than ALSA interface for
the purpose. For good video synchronization there should be timing
feedback from the decoder output (D/A feed stage).
However, these are fairly simple cases compared to environmental 3D
audio... (environment parameters, passive scene objects, active scene
objects with streams, etc) Some of these could be implemented through
ALSA control interface and virtual channels, but there are still various
interaction issues left and those passive objects are a bit problematic
to represent this way.
If I will use sample format "special" will
the alsa know not to try and
do manipulation over it? (resampling, volume, etc...)
One of the common cases would probably be to feed AC-3 or dts audio to
S/PDIF. These should work?
31 May
31 May
7:09 a.m.
The problem with OpenMAX is that most of the common
players (at least
the ones I looked into mplayer and mpg123) doesn't support them
natively.
You could try the gstreamer plugin for openmax.
http://freedesktop.org/wiki/GstOpenMAX
Cheers,
Ste
5:22 p.m.
Thought to score two in one (both un encoded and encoded streams via the
same interface)....
Ok, when passing only PCM is it possible to make a plug-in that will
receive all the control from the ALSA but the data will still pass
through the ALSA to kernel driver?
Will control include receiving mixer, volume, etc ?
Or
Do a plugin for both data and control ? will there be a performance
issue in this case?
-----Original Message-----
From: bluef [mailto:bluefuture@email.it]
Sent: Sunday, May 31, 2009 12:09 PM
To: Ziv Haziz
Cc: Jussi Laako; linux-audio-dev(a)lists.linuxaudio.org
Subject: Re: [LAD] supporting a dedicated DSP chip with ALSA
The problem with OpenMAX is that most of the common
players (at least
the ones I looked into mplayer and mpg123) doesn't support them
natively.
You could try the gstreamer plugin for openmax.
http://freedesktop.org/wiki/GstOpenMAX
Cheers,
Ste
______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using
MessageLabs Email Security System.
_____________________________________________________________________
______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using MessageLabs Email
Security System.
_____________________________________________________________________
5:23 p.m.
bluef schrieb:
If the plugins are yet to be written, then I would write them directly for
gstreamer as there are hardly any openmax applications out there and on the
embedded its good to avoid extra layers. openmax is not that lightwight as it
looks :/
Stefan
The problem
with OpenMAX is that most of the common players (at least
the ones I looked into mplayer and mpg123) doesn't support them
natively.
You could try the gstreamer plugin for openmax.
http://freedesktop.org/wiki/GstOpenMAX
Cheers,
Ste
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
3 Jun
3 Jun
11 a.m.
-----Original Message-----
From: Ziv Haziz
Sent: Sunday, May 31, 2009 10:23 PM
To: 'bluefuture(a)email.it'
Cc: Jussi Laako; linux-audio-dev(a)lists.linuxaudio.org
Subject: RE: [LAD] supporting a dedicated DSP chip with ALSA
Thought to score two in one (both un encoded and encoded streams via the
same interface)....
Ok, when passing only PCM is it possible to make a plug-in that will
receive all the control from the ALSA but the data will still pass
through the ALSA to kernel driver?
Will control include receiving mixer, volume, etc ?
Or
Do a plugin for both data and control ? will there be a performance
issue in this case?
-----Original Message-----
From: bluef [mailto:bluefuture@email.it]
Sent: Sunday, May 31, 2009 12:09 PM
To: Ziv Haziz
Cc: Jussi Laako; linux-audio-dev(a)lists.linuxaudio.org
Subject: Re: [LAD] supporting a dedicated DSP chip with ALSA
The problem with OpenMAX is that most of the common
players (at least
the ones I looked into mplayer and mpg123) doesn't support them
natively.
You could try the gstreamer plugin for openmax.
http://freedesktop.org/wiki/GstOpenMAX
Cheers,
Ste
______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using
MessageLabs Email Security System.
_____________________________________________________________________
______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using MessageLabs Email
Security System.
_____________________________________________________________________
31 May
31 May
5:21 p.m.
Ziv Haziz schrieb:
Hi All,
i'm seeking an advise on the preferred way to support a dedicated DSP
chip under ALSA.
The system is an embedded system constructed on a dual core chip – one
core is ARM vanlia and the other is a dedicated DSP core.
The DSP core is capable of both playing both encoded streams (mp3, wma,
various voice coders) and of course PCM streams.
the codec (a2d, d2a) are connected to DSP.
I think having a alsa support for the PCM is step one. To allow applications to
benefit from the codecs,
you could write wrappers for gstreamer. But basically the later depends if you
have existing applications already.
If then you need to support the interfaces they are using.
Stefan
I looking for an elegant design to hide the DSP under the ALSA sysem and
I have several ideas and would like to get your advise:
1. use LADSPA to make the DSP look as a plug-in for both control and
data – what I don't know is if LADSPA forces me to return data to
the ALSA for sending it to the kernel drivers
2. use the LADSPA to make the DSP control only and make another
kernel driver for the audio data pass – is it possible? There can
be a sync problem between the commands and the time the data will
arrive? Will this support JACKD ?
I'm open to other suggestions as well,
Thanks in advance
Ziv
______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using
MessageLabs Email Security System.
_____________________________________________________________________
------------------------------------------------------------------------
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
5647
days inactive
5652
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
6 participants
participants (6)
-
bluef -
Jussi Laako -
Pieter Palmers -
Ray Rashif -
Stefan Kost -
Ziv Haziz