[issue16902] Add OSS module support for Solaris

[Sebastian Wiedenroth]

Sebastian Wiedenroth  added the comment:

This patch has also been applied to the python versions shipped by OpenIndiana 
and OmniOS for a long time. I'd say it's safe to merge.

--
nosy: +wiedi

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[Tim Mooney]

Tim Mooney added the comment:

Sooo  It's been 3 years.  Brian's patch has bit-rotted a bit, but it's easy 
to update for recent Python.

What are the hold-ups to getting this applied?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[Tim Mooney]

Tim Mooney added the comment:

For what it's worth, I've been using a patch nearly identical to this one with 
python 2.6.x and 2.7.x with good success, and in my case it was under Solaris 
10 with the no-cost oss package from 4Front.  I now have a new workstation 
and I've installed OpenIndiana (one of the OpenSolaris derivatives) on it, so 
I've had to revisit my patch slightly to get it to work with Python 2.7.5.

It causes no real harm to attempt to build ossaudiodev even on earlier Solaris 
platforms that don't have the package installed.  With Brian's patch or mine, 
the build reports that it expected to build ossaudiodev but that build failed.  
There are other modules that setup.py expects to have work on Solaris that do 
not, so this is not the first instance of trying something only to have it 
gracefully fail.  It's really no different from what's being done with linux -- 
setup.py attempts to build ossaudiodev for all Linux distributions, even though 
some of them have ripped out support for OSS, in favor of ALSA or Pulse.

I would agree that using individual ifdef's for each define is useful; it 
appears that the oss package from 4Front provides more of the defines than the 
modified Boomer OSS headers that are part of the OpenSolaris derivatives.

My recommendation would be that Brian's patch or something like it be included 
as a bug fix in any releases of Python, not as just a new feature in the 
latest release.

--
nosy: +enchanter

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[brian-cameron-oracle]

brian-cameron-oracle added the comment:

Since Modules/ossaudiodev.c has the following line (which is not surrounded by 
any conditional #ifdef sort of things):

#include sys/soundcard.h

This means that the OSS plugin will only build on a system that has this header 
file, so it is safe to check for on any system.  How can the Module code build 
if the header can't be found?

The code will only compile if the CFLAGS used when building the
module is setup to include /usr/include or /usr/local/include, but
this is normally taken care of by default.

If users need to specify their OSS headers are in some weird 
non-standard location, then they can use CFLAGS or other Makefile mechanisms to 
specify the compiler arguments they would then need to build anything that uses 
their non-standard OSS.

Or am I just confused by your question?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[brian-cameron-oracle]

New submission from brian-cameron-oracle:

Solaris supports OSS, but the attached patch is needed to get it to build.

Note that some of the EXPORT_INT lines in Modules/ossaudiodev.c need to be
#ifndef'ed out on Sun since OSS on Solaris doesn't support them all. 

Does it make sense to use #ifndef like this, or should each EXPORT_INT be 
encapsulated by its own #ifdef?

--
components: Extension Modules
files: ossaudiodev.patch
keywords: patch
messages: 179424
nosy: brian-cameron-oracle
priority: normal
severity: normal
status: open
title: Add OSS module support for Solaris
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file28644/ossaudiodev.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[Jesús Cea Avión]

Jesús Cea Avión added the comment:

Brian, is this supported in Solaris 10 or Solaris 11?.

How can I actually try it?. I use Solaris on servers, and have Solaris 10/11 
virtual machines in my laptop but never ever used sound under Solaris...

Also, I am unsure about this being a new feature (available in future Python 
3.4) or a bugfix (to be available on 2.7, 3.2, 3.3 and 3.4). Opinions?

--
nosy: +jcea

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[brian-cameron-oracle]

brian-cameron-oracle added the comment:

OSS is the default audio system in Solaris 11 and 12.  In Solaris 10 and 
earlier, the sunaudio (or SADA) interfaces are still used.  You can only test 
this if you are using Solaris 11 or later, on a machine with a sound card 
supported by OSS.

I would say this is really more of a bugfix.  The main problem is that the 
configure script was avoiding even trying to build the OSS module on Solaris, 
and that the code only builds if the ioctls unsupported on Solaris are 
#ifdef'ed out on Solaris.  So it would make sense to support the ability to 
build the OSS module in 2.7, 3.x and onwards.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[Jesús Cea Avión]

Jesús Cea Avión added the comment:

Brian, then this module should be compiled only under Solaris 11 and up and, 
presumably, OpenSolaris/Illumos derivatives.

Does your patch compiles cleanly under previous Solaris versions?.

I am +1 to consider this a bugfix. Any other python-dev opinion?

PS: My virtual machines are configured with AC97 sound. Is that supported under 
Solaris 11?.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[brian-cameron-oracle]

brian-cameron-oracle added the comment:

Correct, OSS should work out-of-the-box on Solaris 11 and up since it is
the default audio system there.  OSS was also integrated into OpenSolaris, so 
it is probably the most sensible audio plugin to use there also.  Some 
end-users may build and install their own OSS code on Solaris 10 or earlier, so 
it should not hurt to try and build the OSS plugin even on older versions of 
Solaris. 

Also, I'm not sure if the way I'm doing the #ifndef's in the patch is right.  
Looking at the rest of the code, I see that each EXPORT_INT is
surrounded by its own #ifdef.  I added similar #ifdef's around 
SNDCTL_DSP_BIND_CHANNEL SNDCTL_DSP_MAPINBUF, and SNDCTL_DSP_MAPOUTBUF.
However I just put #ifndef __sun around the SNDCTL_COPR_* and
SNDCTL_DSP_* ioctls because it seemed to make the patch more simple.
But, I'm not sure this was the right decision.  Maybe it just might be
more consistent to use an #ifdef around each one separately.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[Jesús Cea Avión]

Jesús Cea Avión added the comment:

The problem with your approach is that different Solaris release could support 
different flags. So I rather prefer specific #ifdef's.

I wonder about compiling OSS module under Solaris without OSS support. 
Compiling a module acting as NULL is OK, compiling a node that will crash on 
import, for instance, it is not.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[brian-cameron-oracle]

brian-cameron-oracle added the comment:

Sure, doing multiple #ifdef's makes sense.  Do you need me to provide an 
updated patch, or is this something easier for someone who has commit access to 
the source code repository to just go ahead and do.

I would think this Module would fail to compile if OSS isn't present, no?  So I 
guess I do not understand your comment about this possibly causing any sort of 
crash on import at runtime.

The Modules/ossaudiodev.c file should not compile if 
/usr/include/sys/soundcard.h isn't available with OSS definitions.  It wouldn't 
be on Solaris 10 or earlier.  Is it okay to try and compile this plugin and let 
it fail if it does?  Or does the configure script need to check this first and 
only try building it on Solaris 11 or later?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[Jesús Cea Avión]

Jesús Cea Avión added the comment:

Brian, this patch would try to compile OSS module on any Solaris machine, even 
if not OSS support is provided. That is, compilation would fail in that case. 
That is not acceptable. Some kind of OSS detection is needed.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[brian-cameron-oracle]

brian-cameron-oracle added the comment:

I'm not sure how to write such OSS detection code.  I do know that
OSS is only on Solaris systems that have this OSS-specific file:

/usr/include/sys/soundcard.h

So that's probably the best way to check and it should work even on Solaris 10 
if OSS is already installed by the end-user.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[Jesús Cea Avión]

Jesús Cea Avión added the comment:

Brian, Linux has that include file too. So, yes, I think that detection would 
be appropiate. If we could confirm that all platforms with OSS support have 
that file, we could have something :-).

If not, or we are not sure, just check for that file *IF* the platform is 
sunos5.

Could you possibly provide a new patch with that test and independent #ifdef's?

I am assigning this issue to me. Lets move :-).

--
assignee:  - jcea

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[Jesús Cea Avión]

Jesús Cea Avión added the comment:

For user installed packages, the usual path would be 
/usr/local/include/sys/soundcard.h. So, maybe check both paths. Do you agree?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com