OSS4 for embedded targets

[S***@be.thalesgroup.com]

Hello,

I'm looking for a sound solution to include on an embedded product, but for
support reasons, it would still have to be compatible with a 2.4 kernel.

I was hoping to use OSS4 because its API makes more sense for our target
than our other options.
Unfortunately, currently only 2.6 kernels are supported.

Is there a way I could add a cross-compile option to support the older
kernel ?

Or would this be considered a useless product feature for the effort it
represents ?
If this is a reaonable effort (and deemed useful), I'd be happy to
contribute it.

Alternatively, can I use a slightly older OSS4 build that still has it ?

Thanks a lot,

Sven

Sven Biebaut
[phone]
***@be.thalesgroup.com
----------------------------------------------------------------------------
-
T COMMUNICATIONS BELGIUM
Rue des Frères Taymans 28, B-1480 Tubize, Belgium
Phone: [phone], fax: +32 (0)2
3912300

[Clemens Ladisch]

Post by S***@be.thalesgroup.com
I'm looking for a sound solution to include on an embedded product, but for
support reasons, it would still have to be compatible with a 2.4 kernel.

Is this new software for some old hardware? (2.6.0 was released in 2003.)

Post by S***@be.thalesgroup.com
I was hoping to use OSS4 because its API makes more sense for our target
than our other options.
Unfortunately, currently only 2.6 kernels are supported.
Is there a way I could add a cross-compile option to support the older
kernel ?

It's certainly possible, in theory, but when I look at the 2.4
compatibility code in the alsa-driver package, I'd estimate that
writing this amount of code from scratch would not make sense for you.

The 2.4 kernels have an old veriosn of OSS built in, and most 2.4
distributions included ALSA, which has OSS emulation, so you might
want to use one of those. (But then I don't know if your application
requires some feature of OSS4's implementation of the API.)


Regards,
Clemens

[S***@be.thalesgroup.com]

Post by S***@be.thalesgroup.com

Post by S***@be.thalesgroup.com
I'm looking for a sound solution to include on an embedded product,
but for support reasons, it would still have to be

compatible with a 2.4 kernel.
Is this new software for some old hardware? (2.6.0 was
released in 2003.)

Indeed, the hardware is old (geode GX1) and needs to be supported for quite
a while ...
The goal is to have a (reasonably) common platform for our old and our new
(atom + hd audio) hw.
Adding to the mix is the need to support audio across usb.

Post by S***@be.thalesgroup.com

Post by S***@be.thalesgroup.com
I was hoping to use OSS4 because its API makes more sense for our
target than our other options.
Unfortunately, currently only 2.6 kernels are supported.
Is there a way I could add a cross-compile option to

support the older

Post by S***@be.thalesgroup.com
kernel ?

It's certainly possible, in theory, but when I look at the
2.4 compatibility code in the alsa-driver package, I'd
estimate that writing this amount of code from scratch would
not make sense for you.
The 2.4 kernels have an old veriosn of OSS built in, and most
2.4 distributions included ALSA, which has OSS emulation, so
you might want to use one of those. (But then I don't know
if your application requires some feature of OSS4's
implementation of the API.)

With this in mind, I see that adding 2.4 support would be non trivial
and rather useless for the majority of OSS users,
I will have to consider using 2.6 on our old hardware ...

Thank you for the insight,

Sven Biebaut

[S***@be.thalesgroup.com]

Hello,

Having decided to use 2.6 on my embedded target, I am running into a few
problems that require code/script changes. Hence my post in this channel and
not the general support.

I am more than willing to provide the changes should they appeal ...

My host build environment is a fedora core 3 (no typo ...) and my target is
a GUI less x86 system without development environment.

The following issues arose:
* building libsalsa requires libtool to support --tag, older libtool
versions do not support it yet.
The existence of libtool and/or its support for the parameter could be
checked by the configure script, which could then bail and suggest the user
to use --enable-libsalsa=NO.
* the ogg vorbis support is checked in two directories, however, the
#include statement is formed so it only fits one of both, causing a compile
error when in the other case.
* the graphical tools require gtk support, however the configure does not
check for its presence, nor can they be disabled by the configure.

More issues come from the actual installation on my linker-less target... .
The modules cannot be installed on target via tarball/soundon but they
cannot be created on the host via "make install" without affecting my host
setup.

Can you provide me with pointers how to add support for specifying an
install root, so OSS can be deployed in a temporary location ? This allows
making a root file system that be dumped on my target and does not need
manual adaptations afterwards.

Thanks a lot,

Sven


Sven Biebaut
[phone]
***@be.thalesgroup.com
----------------------------------------------------------------------------
-
T COMMUNICATIONS BELGIUM
Rue des Frères Taymans 28, B-1480 Tubize, Belgium
Phone: [phone], fax: +32 (0)2
3912300

[Yair K.]

Post by S***@be.thalesgroup.com
Hello,
Having decided to use 2.6 on my embedded target, I am running into a few
problems that require code/script changes. Hence my post in this channel
and not the general support.
I am more than willing to provide the changes should they appeal ...

The build system is messy. If you have anything useful I'm sure the list would
like to see it.

Post by S***@be.thalesgroup.com
* building libsalsa requires libtool to support --tag, older libtool
versions do not support it yet.

I wonder if libtool is really necessary for it to build. No matter...

Post by S***@be.thalesgroup.com
The existence of libtool and/or its support for the parameter could be
checked by the configure script, which could then bail and suggest the user
to use --enable-libsalsa=NO.
* the ogg vorbis support is checked in two directories, however, the
#include statement is formed so it only fits one of both, causing a compile
error when in the other case.

The include statement is <vorbis/vorbisfile.h>. Perhaps utils/ossmkdep.h should
just add the /usr/local/include directory?

Post by S***@be.thalesgroup.com
* the graphical tools require gtk support, however the configure does not
check for its presence, nor can they be disabled by the configure.

They are tested later (setup/setupdir.sh, setup/srcconf.c). Yea, adding a
disable switch would be useful. I can send a diff if anyone is interested.

Post by S***@be.thalesgroup.com
More issues come from the actual installation on my linker-less target... .
The modules cannot be installed on target via tarball/soundon but they
cannot be created on the host via "make install" without affecting my host
setup.
Can you provide me with pointers how to add support for specifying an
install root, so OSS can be deployed in a temporary location ? This allows
making a root file system that be dumped on my target and does not need
manual adaptations afterwards.

You can edit setup/Linux/make.local to add a target.

Yours,
Yair K.

[S***@be.thalesgroup.com]

Hello,

Sorry for the late reply, it took a while to try these things out ..

Please find my remarks in line.

-----Original Message-----
Sent: 04 February, 2011 20:37
Subject: Re: [oss-devel] OSS4 for embedded targets
On Thursday 03 February 2011 16:52:20

Post by S***@be.thalesgroup.com
Hello,
Having decided to use 2.6 on my embedded target, I am

running into a

Post by S***@be.thalesgroup.com
few problems that require code/script changes. Hence my

post in this

Post by S***@be.thalesgroup.com
channel and not the general support.
I am more than willing to provide the changes should they appeal ...

The build system is messy. If you have anything useful I'm
sure the list would like to see it.

I can see what you mean now ...
As soon as I figure all the details out, I will make a new topic on this
list.

Post by S***@be.thalesgroup.com
* building libsalsa requires libtool to support --tag,

older libtool

Post by S***@be.thalesgroup.com
versions do not support it yet.

I wonder if libtool is really necessary for it to build. No matter...

Post by S***@be.thalesgroup.com
The existence of libtool and/or its support for the

parameter could

Post by S***@be.thalesgroup.com
be checked by the configure script, which could then bail

and suggest

Post by S***@be.thalesgroup.com
the user to use --enable-libsalsa=NO.

A patch is attached for the configure script that does just that.
For the --tag support I still need to dig a bit further.

Post by S***@be.thalesgroup.com
* the ogg vorbis support is checked in two directories,

however, the

Post by S***@be.thalesgroup.com
#include statement is formed so it only fits one of both, causing a
compile error when in the other case.

The include statement is <vorbis/vorbisfile.h>. Perhaps
utils/ossmkdep.h should just add the /usr/local/include directory?

Post by S***@be.thalesgroup.com
* the graphical tools require gtk support, however the

configure does

Post by S***@be.thalesgroup.com
not check for its presence, nor can they be disabled by the

configure.
They are tested later (setup/setupdir.sh, setup/srcconf.c).
Yea, adding a disable switch would be useful. I can send a
diff if anyone is interested.

Yes please, that would be very useful

Post by S***@be.thalesgroup.com
More issues come from the actual installation on my

linker-less target... .

Post by S***@be.thalesgroup.com
The modules cannot be installed on target via

tarball/soundon but they

Post by S***@be.thalesgroup.com
cannot be created on the host via "make install" without

affecting my

Post by S***@be.thalesgroup.com
host setup.
Can you provide me with pointers how to add support for

specifying an

Post by S***@be.thalesgroup.com
install root, so OSS can be deployed in a temporary location ? This
allows making a root file system that be dumped on my

target and does

Post by S***@be.thalesgroup.com
not need manual adaptations afterwards.

You can edit setup/Linux/make.local to add a target.

I added a remote_install option that passes a directory to install.sh. When
the directory is not specified (as in the normal "make install" or via
soundon ), the install.sh falls back to the default "/".

This morning however, I thought of an alternative, namely to specify this at
configure time. This allows the procedure to be the same,
but requires all scripts to be adapted. OTH, specifying it at the make,
allows the same oss to be installed both on host and on target, although I
do not know if this is useful : on embedded targets the kernel is often
different and most of the time you want explicit control, which means from
the configure stage onwards different parameters passed and a separate build
directory.

What would fit OSS best ?

Thanks in advance,

Sven

[Clemens Ladisch]

Post by S***@be.thalesgroup.com
I added a remote_install option that passes a directory to install.sh. When
the directory is not specified (as in the normal "make install" or via
soundon ), the install.sh falls back to the default "/".
This morning however, I thought of an alternative, namely to specify this at
configure time. This allows the procedure to be the same,
but requires all scripts to be adapted. OTH, specifying it at the make,
allows the same oss to be installed both on host and on target, although I
do not know if this is useful : on embedded targets the kernel is often
different and most of the time you want explicit control, which means from
the configure stage onwards different parameters passed and a separate build
directory.
What would fit OSS best ?

While OSS doesn't officially subject itself to the GNU coding standards,
doing it in any other way would just confuse user needlessly IMNSHO, so
I'd propose to use the DESTDIR variable for make:
http://www.gnu.org/prep/standards/html_node/DESTDIR.html


Regards,
Clemens

[S***@be.thalesgroup.com]

-----Original Message-----
Clemens Ladisch
Sent: 08 February, 2011 15:38
To: Discussion mailing list for developers of OSS
Subject: Re: [oss-devel] OSS4 for embedded targets

Post by S***@be.thalesgroup.com
I added a remote_install option that passes a directory to

install.sh.

Post by S***@be.thalesgroup.com
When the directory is not specified (as in the normal "make

install"

Post by S***@be.thalesgroup.com
or via soundon ), the install.sh falls back to the default "/".
This morning however, I thought of an alternative, namely

to specify

Post by S***@be.thalesgroup.com
this at configure time. This allows the procedure to be the

same, but

Post by S***@be.thalesgroup.com
requires all scripts to be adapted. OTH, specifying it at the make,
allows the same oss to be installed both on host and on target,
although I do not know if this is useful : on embedded targets the
kernel is often different and most of the time you want explicit
control, which means from the configure stage onwards different
parameters passed and a separate build directory.
What would fit OSS best ?

While OSS doesn't officially subject itself to the GNU coding
standards, doing it in any other way would just confuse user
needlessly IMNSHO, so I'd propose to use the DESTDIR variable
http://www.gnu.org/prep/standards/html_node/DESTDIR.html

OK, I wasn't aware of the standard, so I named my variable TARGET_DIR, but I
will rename it.

Thanks,

Sven

Regards,
Clemens
_______________________________________________
oss-devel mailing list
http://mailman.opensound.com/mailman/listinfo/oss-devel