Re: OSS Audio

[blubee blubeeme]

On Mon, Dec 25, 2017 at 12:16 PM, blubee blubeeme 
wrote:

>
>
> On Fri, Dec 22, 2017 at 9:31 PM, Sid  wrote:
>
>> OSS soundcard.h for FreeBSD stable and current
>> https://svn.freebsd.org/base/stable/11/sys/sys/
>> https://svn.freebsd.org/base/head/sys/sys/
>>
>> blubee blubeeme; Mon Dec 11 17:03:10 UTC 2017
>> > I'm taking a look at soundcard.h in /usr/include/sys/soundcard.h in
>> FreeBSD
>> > vs the soundcard.h in the offical OSS 4.01
>> > https://sourceforge.net/p/opensound/git/ci/master/tree/inclu
>> de/soundcard.h
>>
>> > It seems like there's been a lot of changes between FreeBSD 3.8ish
>> version
>> > and the 4.0 version.
>>
>> > I was grepping around to see if any other files included this
>> soundcard.h
>> > header and if updating to the latest would break any other programs.
>>
>
> I've been looking into this for a bit now and these ioctl seems missing or
> returning strange values.
>
> SNDCTL_DSP_COOKEDMODE
> SNDCTL_MIDIINFO
> SNDCTL_MIX_ENUMINFO
> SNDCTL_MIX_EXTINFO
> SNDCTL_CARDINFO
> SNDCTL_GETLABEL
> SNDCTL_SETLABEL
> SNDCTL_GETSONG
> SNDCTL_SETNAME
> SNDCTL_DSP_GET_CHNORDER
>
> oss_digital_control and it's related data structures seems to be missing,
> that needed for digital sources.
> SNDCTL_DSP_READCTL
> SNDCTL_DSP_WRITECTL
>
> The might be implemented in other places if so, where?
>
> I was trying to find some more info about the above functions and came
across this wiki page: https://wiki.freebsd.org/RyanBeasley/ioctlref

It already documents some of the reasons why the specific ioctls weren't
implemented and their progress.
Is there any updated information on this?

There's a huge chunk of code to test digital audio that can't be tested
because of [oss_digital_control] is missing,
code sample below:

#ifdef SHOW_STATUS
  time_t t;
  oss_digital_control c;

  c.valid = VAL_CBITIN | VAL_ISTATUS;

  if (ioctl (fd, SNDCTL_DSP_READCTL, ) == -1)
{
  perror ("SNDCTL_DSP_READCTL");
  exit (-1);
}

  time ();
  printf ("\n%s\n", ctime ());

  if (c.valid & VAL_ISTATUS)
{
  switch (c.in_locked)
{
case LOCK_NOT_INDICATED:
  printf ("Receiver locked: Status unknown\n");
  break;
case LOCK_UNLOCKED:
  printf ("receiver locked: *** NOT LOCKED ***\n");
  break;
case LOCK_LOCKED:
  printf ("receiver locked: Locked OK\n");
  break;
}

  switch (c.in_quality)
{
case IN_QUAL_NOT_INDICATED:
  printf ("Signal quality: Unknown\n");
  break;
case IN_QUAL_POOR:
  printf ("Signal quality: *** POOR ***\n");
  break;
case IN_QUAL_GOOD:
  printf ("Signal quality: Good\n");
  break;
}

  switch (c.in_vbit)
{
case VBIT_NOT_INDICATED:
  printf ("V-bit: Unknown\n");
  break;
case VBIT_ON:
  printf ("V-bit: On (not valid audio)\n");
  break;
case VBIT_OFF:
  printf ("V-bit: Off (valid audio signal)\n");
  break;
}

  switch (c.in_data)
{
case IND_UNKNOWN:
  printf ("Audio/data: Unknown\n");
  break;
case IND_AUDIO:
  printf ("Audio/data: Audio\n");
  break;
case IND_DATA:
  printf ("Audio/data: Data\n");
  break;
}

  printf ("Errors: ");
  if (c.in_errors & INERR_CRC)
printf ("CRC ");
  if (c.in_errors & INERR_QCODE_CRC)
printf ("QCODE_CRC ");
  if (c.in_errors & INERR_PARITY)
printf ("PARITY ");
  if (c.in_errors & INERR_BIPHASE)
printf ("BIPHASE ");
  printf ("\n");
}
  else
printf ("No input status information available\n");

  if (c.valid & VAL_CBITIN && c.in_locked != LOCK_UNLOCKED)
{
  printf ("\n");
  printf ("Control bits: ");
  for (i = 0; i < 24; i++)
printf ("%02x ", c.cbitin[i]);
  printf ("\n");

  if (c.cbitin[0] & 0x01)
decode_pro_mode (c.cbitin);
  else
decode_consumer_mode (c.cbitin);
}
  else
printf ("No incoming control bit information available\n");
#endif


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[blubee blubeeme]

On Fri, Dec 22, 2017 at 9:31 PM, Sid  wrote:

> OSS soundcard.h for FreeBSD stable and current
> https://svn.freebsd.org/base/stable/11/sys/sys/
> https://svn.freebsd.org/base/head/sys/sys/
>
> blubee blubeeme; Mon Dec 11 17:03:10 UTC 2017
> > I'm taking a look at soundcard.h in /usr/include/sys/soundcard.h in
> FreeBSD
> > vs the soundcard.h in the offical OSS 4.01
> > https://sourceforge.net/p/opensound/git/ci/master/tree/
> include/soundcard.h
>
> > It seems like there's been a lot of changes between FreeBSD 3.8ish
> version
> > and the 4.0 version.
>
> > I was grepping around to see if any other files included this soundcard.h
> > header and if updating to the latest would break any other programs.
>

I've been looking into this for a bit now and these ioctl seems missing or
returning strange values.

SNDCTL_DSP_COOKEDMODE
SNDCTL_MIDIINFO
SNDCTL_MIX_ENUMINFO
SNDCTL_MIX_EXTINFO
SNDCTL_CARDINFO
SNDCTL_GETLABEL
SNDCTL_SETLABEL
SNDCTL_GETSONG
SNDCTL_SETNAME
SNDCTL_DSP_GET_CHNORDER

oss_digital_control and it's related data structures seems to be missing,
that needed for digital sources.
SNDCTL_DSP_READCTL
SNDCTL_DSP_WRITECTL

The might be implemented in other places if so, where?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Sid]

OSS soundcard.h for FreeBSD stable and current
https://svn.freebsd.org/base/stable/11/sys/sys/
https://svn.freebsd.org/base/head/sys/sys/

blubee blubeeme; Mon Dec 11 17:03:10 UTC 2017
> I'm taking a look at soundcard.h in /usr/include/sys/soundcard.h in FreeBSD
> vs the soundcard.h in the offical OSS 4.01
> https://sourceforge.net/p/opensound/git/ci/master/tree/include/soundcard.h

> It seems like there's been a lot of changes between FreeBSD 3.8ish version
> and the 4.0 version.

> I was grepping around to see if any other files included this soundcard.h
> header and if updating to the latest would break any other programs.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Sid]

blubee blubeeme; Mon Dec 11 17:03:10 UTC 2017
> I'm taking a look at soundcard.h in /usr/include/sys/soundcard.h in FreeBSD
> vs the soundcard.h in the offical OSS 4.01
> https://sourceforge.net/p/opensound/git/ci/master/tree/include/soundcard.h

> It seems like there's been a lot of changes between FreeBSD 3.8ish version
> and the 4.0 version.

> I was grepping around to see if any other files included this soundcard.h
> header and if updating to the latest would break any other programs.

Can you find OSS version 4.1 or 4.2 in https://svn.freebsd.org/base/ for head/ 
or stable/?

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Alexander Leidinger]

Quoting blubee blubeeme  (from Tue, 19 Dec 2017  
00:28:23 +0800):



there's the alsa-lib from audio/alsa-lib
there's https://sourceforge.net/p/opensound/git/ci/master/tree/lib/libsalsa/
from oss that wraps alsa code, would there be issues with any of that in
the kernel?


Yes there would be an issue. It doesn't belong into the kernel. It's  
an userland library. It belongs into the userland (where it is right  
now) = /usr/local/lib or /usr/lib.


And to answer the question which may come if it makes sense to include  
it into the FreeBSD basesystem (userland) instead of having it in the  
ports collection: right now (without any program in the FreeBSD base  
system) it doesn't make sense. If there is a program which makes use  
of alsa-lib which shall be imported into the FreeBSD basesystem (not  
discussing right now if such a program makes sense in the FreeBSD  
basesystem as we don't have an explicit example to look at), then it  
makes sense.


Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpA2fF9M8flf.pgp
Description: Digitale PGP-Signatur

Re: OSS Audio

[blubee blubeeme]

On Tue, Dec 19, 2017 at 12:11 AM, Alexander Leidinger <
alexan...@leidinger.net> wrote:

>
> Quoting Sid  (from Sat, 16 Dec 2017 23:53:17 +0100):
>
> I've had a few misconceptions.
>>
>> Bluebee Blubeeme said, 4Front has a modern OSS implementation that is
>> under a FreeBSD license.
>>
>> The model of Sound on FreeBSD is, three layers:
>> 1. The API, where programs use libraries (of respective sound
>> architecture) to access the sound server.
>> 2. The sound server: OSS, Sndio, Portaudio, JACK, ALSA, native, etc
>> 3. FreeBSD's base is always OSS (OpenBSD's driver is sndio); sound
>> servers connect to and use this.
>>
>
> It's a little bit different.
>
>  From application to hardware it is like:
>   5) application
>   4) maybe some infrastructure layer (jack, portaudio)
>   3) the API (for linux: ALSA libs, for FreeBSD: opening the device nodes
> and issues ioctls = the OSS API)
>   2) the kernel code
>   1) the hardware
>
> So FreeBSD is a target from layer 2 until layer 3. Everything above
> depends 100% on the application you are using.
>
> The part of OSS in name, that is a mess, is the API structure, and various
>> implementations. In FreeBSD for instance, when a program uses an OSS API, I
>> hear that developers, need to write so many patches, because different OSS
>> frontends are not standardized. Most
>>
>
> FreeBSD implements the OSSv4 API. Maybe not in v4.2, but those are
> extensions are not really that much important for this discussion. The
> important part is, that we support OSSv4 since about FreeBSD 8, and that
> the main part of playing audio is not changed between 4.0 and 4.2, so it
> doesn't matter much if we talk about the FreeBSD implementation of OSSv4 or
> the 4Front implementation of OSSv4.2.
>
> The issues which come at hand are so far either at layer 5 or 4. For
> issues at layer 3 I have not seen any prove or procedure how to repeat the
> issue so far (and I'm interested to see a procedure so that we can repeat
> the issue(s) people talk about here).
>
>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
>

there's the alsa-lib from audio/alsa-lib
there's https://sourceforge.net/p/opensound/git/ci/master/tree/lib/libsalsa/
from oss that wraps alsa code, would there be issues with any of that in
the kernel?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Alexander Leidinger]

Quoting Sid  (from Sat, 16 Dec 2017 23:53:17 +0100):


I've had a few misconceptions.

Bluebee Blubeeme said, 4Front has a modern OSS implementation that  
is under a FreeBSD license.


The model of Sound on FreeBSD is, three layers:
1. The API, where programs use libraries (of respective sound  
architecture) to access the sound server.

2. The sound server: OSS, Sndio, Portaudio, JACK, ALSA, native, etc
3. FreeBSD's base is always OSS (OpenBSD's driver is sndio); sound  
servers connect to and use this.


It's a little bit different.

 From application to hardware it is like:
  5) application
  4) maybe some infrastructure layer (jack, portaudio)
  3) the API (for linux: ALSA libs, for FreeBSD: opening the device  
nodes and issues ioctls = the OSS API)

  2) the kernel code
  1) the hardware

So FreeBSD is a target from layer 2 until layer 3. Everything above  
depends 100% on the application you are using.


The part of OSS in name, that is a mess, is the API structure, and  
various implementations. In FreeBSD for instance, when a program  
uses an OSS API, I hear that developers, need to write so many  
patches, because different OSS frontends are not standardized. Most


FreeBSD implements the OSSv4 API. Maybe not in v4.2, but those are  
extensions are not really that much important for this discussion. The  
important part is, that we support OSSv4 since about FreeBSD 8, and  
that the main part of playing audio is not changed between 4.0 and  
4.2, so it doesn't matter much if we talk about the FreeBSD  
implementation of OSSv4 or the 4Front implementation of OSSv4.2.


The issues which come at hand are so far either at layer 5 or 4. For  
issues at layer 3 I have not seen any prove or procedure how to repeat  
the issue so far (and I'm interested to see a procedure so that we can  
repeat the issue(s) people talk about here).


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgp67Ffe5iiy9.pgp
Description: Digitale PGP-Signatur

Re: OSS Audio

[Alexander Leidinger]

Quoting Sid  (from Sun, 17 Dec 2017 19:18:23 +0100):


Having proper Audio programming guide in the FreeBSD handbook
ditch sndio and all that other stuff and move forward with a clean start
and proper documentation for new audio programs.


If 4Font OSS 4.x comes along, sndio's and portaudio's servers should


The FreeBSD sound system already implements the OSSv4 API since about  
FreeBSD 8.


be stripped down, to work on top of, and not duplicate OSS's server  
implementation, so the API of many programs that already use it,


If they wouldn't use the OSS API on FreeBSD, they wouldn't be able to  
play and sound. If they use it to the full extend what is possible and  
makes sense, I don't know. Anyone is free to work with the developers  
of those servers to improve the FreeBSD parts in those programs.


readily will. I also wish there were a FreeBSD patch for ALSA and  
other Linuxism API's to just connect directly to OSS or Sndio's


Isn't this what the port audio/alsa-lib is about?


server. Canberra's (computer sounds output) API especially needs to


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgp89bkidfS8o.pgp
Description: Digitale PGP-Signatur

Re: OSS Audio

[blubee blubeeme]

On Mon, Dec 18, 2017, 02:18 Sid  wrote:

> >> Stefan Esser; Sun Dec 17 13:11:22 UTC 2017
> >> Do you propose to just update the code to what 4Front provides?
>
> >> This may work for you as individual user, but the 4Front license makes
> >> it impossible to commit that version to FreeBSD. (That was the reason
> >> to stay at a reasonably licensed version, very long ago.)
>
> >> Or do you propose a clean-room implementation that in the end is fully
> >> compatible with 4Front OSS 4.x, but does not violate their license and
> >> intellectual property rights?
>
> >> You are welcome to start with such a clean-room implementation and it
> >> may even be accepted into FreeBSD, once you are ready (provided there
> >> really is no risk of legal problems in any part of the world).
>
> > blubee blubeeme; Sun Dec 17 13:57:40 UTC 2017
> > This is not true. The source code is distributed under different license
> > based on the OS.
> > Look at audio/oss src build process.
>
> > If the code is compiled on Linux it has some Linux type gpl license, if
> > it's on a *BSD it has BSD license, there's also license that suits other
> > platforms as well.
>
> > There were some closed sourced parts because Hannu was trying different
> > license models to pay the bills but instead of supporting him, everyone
> > forked his code and left so he went on to do something else.
>
> http://developer.opensound.com/opensource_oss/licensing.html
> It says most of it is available under a FreeBSD license, but there are
> parts of it, that are closed sourced.
> I'm not sure if any of the closed sourced code is in that download.
> If any closed sourced or GPL code is it in, it would have to be forked it
> to github, sourceforge or other repository, to include only FreeBSD
> licensed code.
>
If you go grab the source code and just do the build steps you'll see that
the license is applied at build time based on the underlying OS.

>
> > blubee blubeeme; Sun Dec 17 13:57:40 UTC 2017
> > I propose properly implementing 4Font OSS 4.x in the FreeBSD kernel,
> > properly using the API as documented on 4Front website.
> > Have 4Front OSS the default audio system in FreeBSD
>
> > Having proper Audio programming guide in the FreeBSD handbook
> > ditch sndio and all that other stuff and move forward with a clean start
> > and proper documentation for new audio programs.
>
> If 4Font OSS 4.x comes along, sndio's and portaudio's servers should be
> stripped down, to work on top of, and not duplicate OSS's server
> implementation, so the API of many programs that already use it, readily
> will. I also wish there were a FreeBSD patch for ALSA and other Linuxism
> API's to just connect directly to OSS or Sndio's server. Canberra's
> (computer sounds output) API especially needs to drop directly to OSS's
> sound server. The reason parts of sndio and portaudio should stay
> available, is that they've done a lot of work this year to fix most ports
> to work with sndio, and keeping compatibility with these two, will make
> porting easier from other BSDs, including GNU programs that already got
> ported to other BSDs.
>
This should be possible since most of this code is trying to do stuff that
4Front OSS does already.

Please remember that it was Hannu who wrote the first sound driver for
Linux and it's his work that most open source audio drivers is based on.

He implemented a midi sequencer before the official midi 1.0 spec was
finalized.

> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Sid]

>> Stefan Esser; Sun Dec 17 13:11:22 UTC 2017
>> Do you propose to just update the code to what 4Front provides?

>> This may work for you as individual user, but the 4Front license makes
>> it impossible to commit that version to FreeBSD. (That was the reason
>> to stay at a reasonably licensed version, very long ago.)

>> Or do you propose a clean-room implementation that in the end is fully
>> compatible with 4Front OSS 4.x, but does not violate their license and
>> intellectual property rights?

>> You are welcome to start with such a clean-room implementation and it
>> may even be accepted into FreeBSD, once you are ready (provided there
>> really is no risk of legal problems in any part of the world).

> blubee blubeeme; Sun Dec 17 13:57:40 UTC 2017
> This is not true. The source code is distributed under different license
> based on the OS.
> Look at audio/oss src build process.

> If the code is compiled on Linux it has some Linux type gpl license, if
> it's on a *BSD it has BSD license, there's also license that suits other
> platforms as well.

> There were some closed sourced parts because Hannu was trying different
> license models to pay the bills but instead of supporting him, everyone
> forked his code and left so he went on to do something else.

http://developer.opensound.com/opensource_oss/licensing.html
It says most of it is available under a FreeBSD license, but there are parts of 
it, that are closed sourced.
I'm not sure if any of the closed sourced code is in that download.
If any closed sourced or GPL code is it in, it would have to be forked it to 
github, sourceforge or other repository, to include only FreeBSD licensed code.

> blubee blubeeme; Sun Dec 17 13:57:40 UTC 2017
> I propose properly implementing 4Font OSS 4.x in the FreeBSD kernel,
> properly using the API as documented on 4Front website.
> Have 4Front OSS the default audio system in FreeBSD

> Having proper Audio programming guide in the FreeBSD handbook
> ditch sndio and all that other stuff and move forward with a clean start
> and proper documentation for new audio programs.

If 4Font OSS 4.x comes along, sndio's and portaudio's servers should be 
stripped down, to work on top of, and not duplicate OSS's server 
implementation, so the API of many programs that already use it, readily will. 
I also wish there were a FreeBSD patch for ALSA and other Linuxism API's to 
just connect directly to OSS or Sndio's server. Canberra's (computer sounds 
output) API especially needs to drop directly to OSS's sound server. The reason 
parts of sndio and portaudio should stay available, is that they've done a lot 
of work this year to fix most ports to work with sndio, and keeping 
compatibility with these two, will make porting easier from other BSDs, 
including GNU programs that already got ported to other BSDs.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[blubee blubeeme]

On Sun, Dec 17, 2017 at 9:11 PM, Stefan Esser  wrote:

> Am 17.12.17 um 02:06 schrieb blubee blubeeme:
> > This is why I am bringing up the issue and why I said the first step
> would
> > be porting the proper 4Front OSS into the kernel.
> >
> > It doesn't have to be the default at first but if it's not in the kernel
> > why bother wasting time to have it rejected because of all the
> > misconceptions I've been dealing with in these threads.
> >
> > Add 4Front OSS to the kernel
> > Use the 4.x API/ Documentation
> > Add it to an audio programming section of FBSD Handbook
> > Upstream changes that make sense
> > Simplify audio programming, documentation, all those audio sound servers
> > Port device drivers to the OSS Device Driver API:
> > http://manuals.opensound.com/sources/drv_index.html
>
> Do you propose to just update the code to what 4Front provides?
>
> This may work for you as individual user, but the 4Front license

This is not true. The source code is distributed under different license
based on the OS.
Look at audio/oss src build process.

If the code is compiled on Linux it has some Linux type gpl license, if
it's on a *BSD it has BSD license, there's also license that suits other
platforms as well.

There were some closed sourced parts because Hannu was trying different
license models to pay the bills but instead of supporting him, everyone
forked his code and left so he went on to do something else.


> makes
> it impossible to commit that version to FreeBSD. (That was the reason
> to stay at a reasonably licensed version, very long ago.)
>
> It seems like everyone has this cloud of OSS is crap floating around in
their minds, the guy just wanted to be able to work on his code and not
have to write windows drivers at the same time, that's not how things
played out.



> Or do you propose a clean-room implementation that in the end is fully
> compatible with 4Front OSS 4.x, but does not violate their license and
> intellectual property rights?
>
> You are welcome to start with such a clean-room implementation and it
> may even be accepted into FreeBSD, once you are ready (provided there
> really is no risk of legal problems in any part of the world).
>
> Regards, STefan
>

FreeBSD doesn't have many if any audio programmers, most of the programs
are ported from other platforms that do not follow good practices, then new
devs
come along, copy the old coding style and keep on perpetuating the bad
habits.


I propose properly implementing 4Font OSS 4.x in the FreeBSD kernel,
properly using the API as documented on 4Front website.
Have 4Front OSS the default audio system in FreeBSD

Having proper Audio programming guide in the FreeBSD handbook
ditch sndio and all that other stuff and move forward with a clean start
and proper documentation for new audio programs.

That's why I brought this issue up on this list is to try and hear from
people who are
doing audio but instead it's just a bunch of noise and misconceptions.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Stefan Esser]

Am 17.12.17 um 02:06 schrieb blubee blubeeme:
> This is why I am bringing up the issue and why I said the first step would
> be porting the proper 4Front OSS into the kernel.
> 
> It doesn't have to be the default at first but if it's not in the kernel
> why bother wasting time to have it rejected because of all the
> misconceptions I've been dealing with in these threads.
> 
> Add 4Front OSS to the kernel
> Use the 4.x API/ Documentation
> Add it to an audio programming section of FBSD Handbook
> Upstream changes that make sense
> Simplify audio programming, documentation, all those audio sound servers
> Port device drivers to the OSS Device Driver API:
> http://manuals.opensound.com/sources/drv_index.html

Do you propose to just update the code to what 4Front provides?

This may work for you as individual user, but the 4Front license makes
it impossible to commit that version to FreeBSD. (That was the reason
to stay at a reasonably licensed version, very long ago.)

Or do you propose a clean-room implementation that in the end is fully
compatible with 4Front OSS 4.x, but does not violate their license and
intellectual property rights?

You are welcome to start with such a clean-room implementation and it
may even be accepted into FreeBSD, once you are ready (provided there
really is no risk of legal problems in any part of the world).

Regards, STefan
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[blubee blubeeme]

On Sun, Dec 17, 2017 at 6:53 AM, Sid  wrote:

> I've had a few misconceptions.
>
> Bluebee Blubeeme said, 4Front has a modern OSS implementation that is
> under a FreeBSD license.
>
> The model of Sound on FreeBSD is, three layers:
> 1. The API, where programs use libraries (of respective sound
> architecture) to access the sound server.
> 2. The sound server: OSS, Sndio, Portaudio, JACK, ALSA, native, etc
> 3. FreeBSD's base is always OSS (OpenBSD's driver is sndio); sound servers
> connect to and use this.
>
FreeBSD base is an older fork of 4Front OSS, somewhere around version 3
something.
There's a 3,200 line diff between freebsd /sys/sys/soundcard.h and the one
available in 4Front repo right now, there's been a lot of improvements
between FreeBSD fork and 4Front OSS 4.2
Plus the OSS 4.x soundcard.h handles ALL legacy devices. The main thing
that changed is the API, follow updated coding styles for new applications
while old applications still just work.

The sound server madness goes away with 4Front OSS.
The API would be stable with 4Front OSS
There's no single place with a more straight forward audio programming
guide online compared to this: http://manuals.opensound.com/developer/

If there is please share.

To use 4Front's OSS, FreeBSD's kernel will have to be recompiled without
> OSS, "snd" and "sound" references, and then that version of OSS installed.
>

without the legacy oss, snd and sound references. That would be replaced by
the 4Front OSS implementation. Then improvements/ fixes can be made on our
end and tried to have upstreamed.
The API is stable, well documented and the sound server madness goes away
as well.

>
> The part of OSS in name, that is a mess, is the API structure, and various
> implementations. In FreeBSD for instance, when a program uses an OSS API, I
> hear that developers, need to write so many patches, because different OSS
> frontends are not standardized. Most applications in ports use Sndio,
> because across BSD's the API to it is standard. Bluebee claims that
> 4Front's OSS is standard as well. As for API on programs/ports, just use
> the FreeBSD API that is available for it, OSS, Sndio, Portaudio, to connect
> to that sound server.
>

This is what can happen w/ open source software. Everyone took from Hannu's
work and then no one credited him for his accomplishments but everyone dog
piles on him.

>
> As long as OSS covers the wide range of implementations of it, OSS In
> Name, without clarifiers, will carry this burden of being complex and
> having a nonstandard API, even when certain implementations don't or may
> not have this issue.
>

This is a Linuxism, spread right around the time they wanted to push ALSA.
Since there are very few to NO audio developers who build software from the
ground up for FreeBSD, all these Linuxism seeped in through the porting of
software from Linux to FreeBSD.

>
> Bluebee says, to my understanding, that 4Front's OSS doesn't have certain
> coding inefficiencies that certain sound architectures have. That is
> something for the developers to be informed about, and to consider in
> FreeBSD current.
>

This is why I am bringing up the issue and why I said the first step would
be porting the proper 4Front OSS into the kernel.

It doesn't have to be the default at first but if it's not in the kernel
why bother wasting time to have it rejected because of all the
misconceptions I've been dealing with in these threads.

Add 4Front OSS to the kernel
Use the 4.x API/ Documentation
Add it to an audio programming section of FBSD Handbook
Upstream changes that make sense
Simplify audio programming, documentation, all those audio sound servers
Port device drivers to the OSS Device Driver API:
http://manuals.opensound.com/sources/drv_index.html

> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>

That's a lot of work and without being able to get this into the kernel
because people just say "oss is a mess" isn't a valid reason.
A lot of these opinions seeped into FreeBSD from other sources.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Sid]

I've had a few misconceptions.

Bluebee Blubeeme said, 4Front has a modern OSS implementation that is under a 
FreeBSD license.

The model of Sound on FreeBSD is, three layers:
1. The API, where programs use libraries (of respective sound architecture) to 
access the sound server.
2. The sound server: OSS, Sndio, Portaudio, JACK, ALSA, native, etc
3. FreeBSD's base is always OSS (OpenBSD's driver is sndio); sound servers 
connect to and use this.

To use 4Front's OSS, FreeBSD's kernel will have to be recompiled without OSS, 
"snd" and "sound" references, and then that version of OSS installed.

The part of OSS in name, that is a mess, is the API structure, and various 
implementations. In FreeBSD for instance, when a program uses an OSS API, I 
hear that developers, need to write so many patches, because different OSS 
frontends are not standardized. Most applications in ports use Sndio, because 
across BSD's the API to it is standard. Bluebee claims that 4Front's OSS is 
standard as well. As for API on programs/ports, just use the FreeBSD API that 
is available for it, OSS, Sndio, Portaudio, to connect to that sound server.

As long as OSS covers the wide range of implementations of it, OSS In Name, 
without clarifiers, will carry this burden of being complex and having a 
nonstandard API, even when certain implementations don't or may not have this 
issue.

Bluebee says, to my understanding, that 4Front's OSS doesn't have certain 
coding inefficiencies that certain sound architectures have. That is something 
for the developers to be informed about, and to consider in FreeBSD current.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Sid]

>> Sid; Fri Dec 15 23:05:47 UTC 2017
>> It's not that FreeBSD is limiting features, it is more that, OSS is a 
>> cluster of complexities,
>> when it is brought to FreeBSD, it is cleaned up, trimmed, and made efficient 
>> for this OS.

> blubee blubeeme; Sat Dec 16 01:40:13 UTC 2017
> This is where the issue lies, FreeBSD's oss "compatible" implementation did 
> some things that went against the design of oss4 and re-introduced and will 
> see that bad audio > programming habits are carried forward into the future.
> This makes it hard to find and fix the root cause of the problems but instead 
> of doing that, people just keep on creating new audio infrastructure.
 
> Why?

"there are so many different OSS implementations, not all of them compatible. 
Even Linux before 2.4 had an OSS implementation until it got replaced with 
ALSA. Sndio is standardized, it's the same on all BSDs. Because it's the same 
for all BSDs it's easier for an application programmer to use it and not have 
to make dozens of exceptions in the code." 
https://forums.freebsd.org/threads/60852/

This is an answer, but I supposed that OSS being an unstandardized tangled 
cluster of code is not the answer you're looking for.

If http://opensound.com/ is the 4Front you're talking about, it is simply their 
oss license agreement, 
https://sourceforge.net/p/opensound/git/ci/master/tree/EULA, which is not 
compatible with a BSD or any opensource license, which is enough for FreeBSD 
not to include it in the base. Aside from it not being incompatible, FreeBSD 
would get sued for using it in their base, because that license says it can 
only be used by each person on one computer at a time, and can't be 
redistributed. As I've mentioned before, many projects took OSS, made it into 
their own, forked it and the licenses. They can take those forks, but once they 
change to a restrictive license, it can't come back here. Again, OSS has many 
implementations which are a cluster of tangled sourcecode and licenses.

If you need details on why developers made decisions on how they programmed it, 
or what they got from it, then they'll have to chime in.

Use sndio or portaudio for MIDI whenever available instead. In most cases, 
developers will have to install that frontend into music programs.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[blubee blubeeme]

On Sat, Dec 16, 2017 at 7:05 AM, Sid  wrote:

> > Yuri; Fri Dec 15 20:22:24 UTC 2017
> > Jack isn't needed in theory, but OSS drivers for many popular sound
> > devices don't support midi. PCI audio devices generally don't support
> > midi, only USB ones do. So if you want midi, you have to go with
> > soft-midi (ex. Jack+fluidsynth).
>
> > Jack is a very powerful audio server, though a bit buggy.
>
> sndiod covers MIDI hardware, which is installed by audio/sndio
> Now I get it, I think she is looking for MIDI, and driver capabilities for
> physical hardware.
>
> > Freddie Cash; Fri Dec 15 16:22:36 UTC 2017
> ​> FreeBSD has had the ability to play sounds from multiple programs
> > simultaneously since the 4.x days.  Back then, the kernel developed a
> > "virtual channels" layer to accommodate this (program X uses /dev/dsp0,
> > program Y uses /dev/dsp1, program Z uses /dev/dsp2, audio is mixed and
> > played out the speakers together).  Later this was done automatically by
> > multiple programs simply accessing /dev/dsp.
>
> This was my misconception. I think what happened is, the frontend/API for
> many programs from the
> portstree got improved this year, when sndio was brought over allowing
> different programs
> to access these drivers at once. It was easier for them to bring make
> those adjustments,
> when it was fixed for that other operating system.
>
> This is a description of sndio on FreeBSD.
> https://forums.freebsd.org/threads/62892/#post-363265
> https://forums.freebsd.org/threads/43417/#post-368500
>
> From what I understand is, that OSS and Sndio have their drivers in the
> /dev/ directory,
> and separately have a frontend or API to connect to user programs.
> OSS hardware drivers are compiled into the kernel or started as modules.
> Sndiod hardware drivers can also be turned on, to be seen in /dev/.
>
> > blubee blubeeme;
> > If you want to test for yourself, install audio/oss then run osstest and
> > report back.
>
> The program audio/oss is a frontend. FreeBSD by default uses OSS hardware
> drivers,
> as that's what most sound devices in /dev/ are. To use a newer OSS
> backend/hardware driver,
> you'd have to get updated source if available, and recompile your kernel.
>
> It's not that FreeBSD is limiting features, it is more that, OSS is a
> cluster of complexities,
> when it is brought to FreeBSD, it is cleaned up, trimmed, and made
> efficient for this OS.
>
> This is where the issue lies, FreeBSD's oss "compatible" implementation
did some things that went against the design of oss4 and re-introduced and
will see that bad audio programming habits are carried forward into the
future.
This makes it hard to find and fix the root cause of the problems but
instead of doing that, people just keep on creating new audio
infrastructure.

Why?


Different frontends/API's (ALSA, JACK, PULSEAUDIO, OSS, SNDIO, native APIs)
> just work together
> on top of FreeBSD's native OSS hardware driver.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Sid]

> Yuri; Fri Dec 15 20:22:24 UTC 2017
> Jack isn't needed in theory, but OSS drivers for many popular sound 
> devices don't support midi. PCI audio devices generally don't support 
> midi, only USB ones do. So if you want midi, you have to go with 
> soft-midi (ex. Jack+fluidsynth).

> Jack is a very powerful audio server, though a bit buggy.

sndiod covers MIDI hardware, which is installed by audio/sndio
Now I get it, I think she is looking for MIDI, and driver capabilities for 
physical hardware.

> Freddie Cash; Fri Dec 15 16:22:36 UTC 2017
​> FreeBSD has had the ability to play sounds from multiple programs
> simultaneously since the 4.x days.  Back then, the kernel developed a
> "virtual channels" layer to accommodate this (program X uses /dev/dsp0,
> program Y uses /dev/dsp1, program Z uses /dev/dsp2, audio is mixed and
> played out the speakers together).  Later this was done automatically by
> multiple programs simply accessing /dev/dsp.

This was my misconception. I think what happened is, the frontend/API for many 
programs from the
portstree got improved this year, when sndio was brought over allowing 
different programs
to access these drivers at once. It was easier for them to bring make those 
adjustments,
when it was fixed for that other operating system.

This is a description of sndio on FreeBSD.
https://forums.freebsd.org/threads/62892/#post-363265
https://forums.freebsd.org/threads/43417/#post-368500

From what I understand is, that OSS and Sndio have their drivers in the /dev/ 
directory,
and separately have a frontend or API to connect to user programs.
OSS hardware drivers are compiled into the kernel or started as modules.
Sndiod hardware drivers can also be turned on, to be seen in /dev/.

> blubee blubeeme;
> If you want to test for yourself, install audio/oss then run osstest and
> report back.

The program audio/oss is a frontend. FreeBSD by default uses OSS hardware 
drivers,
as that's what most sound devices in /dev/ are. To use a newer OSS 
backend/hardware driver,
you'd have to get updated source if available, and recompile your kernel.

It's not that FreeBSD is limiting features, it is more that, OSS is a cluster 
of complexities,
when it is brought to FreeBSD, it is cleaned up, trimmed, and made efficient 
for this OS.

Different frontends/API's (ALSA, JACK, PULSEAUDIO, OSS, SNDIO, native APIs) 
just work together
on top of FreeBSD's native OSS hardware driver.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Yuri]

On 12/15/17 02:30, Sid wrote:

That's good that Jack isn't needed.



Jack isn't needed in theory, but OSS drivers for many popular sound 
devices don't support midi. PCI audio devices generally don't support 
midi, only USB ones do. So if you want midi, you have to go with 
soft-midi (ex. Jack+fluidsynth).


Jack is a very powerful audio server, though a bit buggy.


Yuri

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Re: OSS Audio

[Freddie Cash]

On Fri, Dec 15, 2017 at 2:30 AM, Sid  wrote:

> That's good that Jack isn't needed.
> It appears, as of the last few months or year, OSS is able to play sounds
> from different programs simultaneously.
>

​FreeBSD has had the ability to play sounds from multiple programs
simultaneously since the 4.x days.  Back then, the kernel developed a
"virtual channels" layer to accommodate this (program X uses /dev/dsp0,
program Y uses /dev/dsp1, program Z uses /dev/dsp2, audio is mixed and
played out the speakers together).  Later this was done automatically by
multiple programs simply accessing /dev/dsp.

This was one of the nicer features of FreeBSD 4.x; especially considering
the giant cluster-F that audio was on Linux at the time.  Their OSS
implementation was limited to a single program accessing /dev/dsp at a
time, and led to the development of all kinds of userland audio daemons and
mixers, and started them down the road to ALSA and eventually PulseAudio
(rather than simply fixing the issue in their OSS implementation).

KDE 3.x on FreeBSD 4.x was a multimedia wonder and so easy to get working
compared to KDE 3 on Linux.  KDE 4 and Phonon made this even nicer.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Re: OSS Audio

[blubee blubeeme]

On Fri, Dec 15, 2017 at 6:30 PM, Sid <s...@bsdmail.com> wrote:

> That's good that Jack isn't needed.
> It appears, as of the last few months or year, OSS is able to play sounds
> from different programs simultaneously.
>
> What about physical input jacks for mic and line in?
>   # cat /dev/sndstat
>   installed devices
>   pcm0:  (play/rec) default
>   pcm1:  (play/rec)
>   pcm2:  (play)
>   pcm3:  (play)
>   pcm4:  (play)
> One cluster of physical inputs/outputs can be chosen, but using more than
> one set of inputs isn't always necessary.
>
> There are different implementations of OSS, because it has been often
> forked or added into various projects, including under less permissive
> licenses, still under the OSS name, to many times become cluttered. This is
> common for a project of a permissive license to be taken in by various
> projects, such as ALSA, that use GPL or even proprietary licenses. Most
> forked OSS versions are made to suit or work under other sound
> architectures, applications or an OS's purposes, not necessarily making
> them better. I realize that FreeBSD's version of OSS is not depreciated, is
> fairly efficient, and is functional as it is what FreeBSD uses as
> /dev/sndstat. For the sound frontend, it depends on what the port/program
> has available from OSS, SNDIO or portaudio, to play on FreeBSD's OSS
> backend.
>
> I have a laptop with onboard stuff:
Installed devices:
pcm0:  (play/rec) default
pcm1:  (play)
pcm2:  (play)
No devices installed from userspace.

The issue is FreeBSD doesn't have a lot of devs and instead of bringing
what FreeBSD has inline with upstream, it seems like they want to say nope,
just gonna keep on using our half forked version.

>
> > blubee blubeeme gurenchan at gmail.com - Fri Dec 15 07:49:28 UTC 2017
>
> >> If I can provide OSS audio/midi input and output for the tools that I
> use,
> >> then I can do all the routing natively with OSS.
>
> > There's nothing in FreeBSD that makes the sound architecture only
> support 1 audio device.
>

This 1 audio device thing hasn't been true for a very long time. It's
things like these that go unchallenged and cause confusion.

> These were issues with earlier versions of OSS implementation; please
> remember the days of rebooting your system to get new devices to show up.
>
> > All those issues have been sorted out in OSS 4.0 and above.
>
> > OSS API is like working with file descriptors;
>
> > The open() system call
> > The close() system call
> > The read() system call
> > The write() system call
> > The ioctl() system call
> > The select() and poll() system calls
> > The mmap() system call
>
>
> > Jack audio is NOT necessary, I already ported amsynth over to FreeBSD,
> they had a very old implementation of OSS backend for midi that just worked
> with my midi keyboard.
> > I spoke to the developer and he also updated his code to the newest
> version of OSS, here's some code: https://github.com/
> amsynth/amsynth/commit/7171bd4d945c5938442b80f4276b7e096f06a3a0#diff-
> 0b31b8315cadf5e7556f54a245817f90[https://github.com/amsynth/
> amsynth/commit/7171bd4d945c5938442b80f4276b7e096f06a3a0#diff-
> 0b31b8315cadf5e7556f54a245817f90]
>
> > There's a lot of misinfo out there about OSS being depreciated or dead,
> that's not the case.
> > From looking at what's available OSS is one of the most straight forward
> and stable Audio API's out there.
>
> > If you want to test for yourself, install audio/oss then run osstest and
> report back.
>
> > There's ALSA plugins for OSS that would provide better audio vs the way
> things are implemented right now.
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Re: OSS Audio

[Sid]

That's good that Jack isn't needed.
It appears, as of the last few months or year, OSS is able to play sounds from 
different programs simultaneously.

What about physical input jacks for mic and line in?
  # cat /dev/sndstat
  installed devices
  pcm0:  (play/rec) default
  pcm1:  (play/rec)
  pcm2:  (play)
  pcm3:  (play)
  pcm4:  (play)
One cluster of physical inputs/outputs can be chosen, but using more than one 
set of inputs isn't always necessary.

There are different implementations of OSS, because it has been often forked or 
added into various projects, including under less permissive licenses, still 
under the OSS name, to many times become cluttered. This is common for a 
project of a permissive license to be taken in by various projects, such as 
ALSA, that use GPL or even proprietary licenses. Most forked OSS versions are 
made to suit or work under other sound architectures, applications or an OS's 
purposes, not necessarily making them better. I realize that FreeBSD's version 
of OSS is not depreciated, is fairly efficient, and is functional as it is what 
FreeBSD uses as /dev/sndstat. For the sound frontend, it depends on what the 
port/program has available from OSS, SNDIO or portaudio, to play on FreeBSD's 
OSS backend.

 
> blubee blubeeme gurenchan at gmail.com - Fri Dec 15 07:49:28 UTC 2017

>> If I can provide OSS audio/midi input and output for the tools that I use,
>> then I can do all the routing natively with OSS.

> There's nothing in FreeBSD that makes the sound architecture only support 1 
> audio device.
> These were issues with earlier versions of OSS implementation; please 
> remember the days of rebooting your system to get new devices to show up.
 
> All those issues have been sorted out in OSS 4.0 and above.
 
> OSS API is like working with file descriptors;

> The open() system call
> The close() system call
> The read() system call
> The write() system call
> The ioctl() system call
> The select() and poll() system calls
> The mmap() system call
 
 
> Jack audio is NOT necessary, I already ported amsynth over to FreeBSD, they 
> had a very old implementation of OSS backend for midi that just worked with 
> my midi keyboard.
> I spoke to the developer and he also updated his code to the newest version 
> of OSS, here's some code: 
> https://github.com/amsynth/amsynth/commit/7171bd4d945c5938442b80f4276b7e096f06a3a0#diff-0b31b8315cadf5e7556f54a245817f90[https://github.com/amsynth/amsynth/commit/7171bd4d945c5938442b80f4276b7e096f06a3a0#diff-0b31b8315cadf5e7556f54a245817f90]
 
> There's a lot of misinfo out there about OSS being depreciated or dead, 
> that's not the case.
> From looking at what's available OSS is one of the most straight forward and 
> stable Audio API's out there.
 
> If you want to test for yourself, install audio/oss then run osstest and 
> report back.
 
> There's ALSA plugins for OSS that would provide better audio vs the way 
> things are implemented right now.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Re: OSS Audio

[blubee blubeeme]

On Fri, Dec 15, 2017 at 9:26 AM, Sid <s...@bsdmail.com> wrote:

> > blubee blubeeme - Tue Dec 5 00:48:05 UTC 2017
>
> > If I can provide OSS audio/midi input and output for the tools that I
> use,
> > then I can do all the routing natively with OSS.
>
> A problem with this is FreeBSD's backend sound architecture allows one
> device input or output at a time.
> cat /dev/sndstat shows this, which I believe is OSS. There is sndio's
> backend sndiod (from OpenBSD) that can alternatively be enabled, but I hear
> the volume on it is too low, and I'm not sure if it allows multiple
> devices. sndiod's backend can be enabled by service sndiod start: it is in
> /usr/local/etc/rc.d/.
>
There's nothing in FreeBSD that makes the sound architecture only support 1
audio device.
These were issues with earlier versions of OSS implementation; please
remember the days of rebooting your system to get new devices to show up.

All those issues have been sorted out in OSS 4.0 and above.

OSS API is like working with file descriptors;
The open() system call
The close() system call
The read() system call
The write() system call
The ioctl() system call
The select() and poll() system calls
The mmap() system call

What's complicated about that?

Jack audio is NOT necessary, I already ported amsynth over to FreeBSD, they
had a very old implementation of OSS backend for midi that just worked with
my midi keyboard.
I spoke to the developer and he also updated his code to the newest version
of OSS, here's some code:
https://github.com/amsynth/amsynth/commit/7171bd4d945c5938442b80f4276b7e096f06a3a0#diff-0b31b8315cadf5e7556f54a245817f90

There's a lot of misinfo out there about OSS being depreciated or dead,
that's not the case.
>From looking at what's available OSS is one of the most straight forward
and stable Audio API's out there.

If you want to test for yourself, install audio/oss then run osstest and
report back.

There's ALSA plugins for OSS that would provide better audio vs the way
things are implemented right now.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Re: OSS Audio

[Sid]

> blubee blubeeme - Tue Dec 5 00:48:05 UTC 2017

> If I can provide OSS audio/midi input and output for the tools that I use,
> then I can do all the routing natively with OSS.

A problem with this is FreeBSD's backend sound architecture allows one device 
input or output at a time.
cat /dev/sndstat shows this, which I believe is OSS. There is sndio's backend 
sndiod (from OpenBSD) that can alternatively be enabled, but I hear the volume 
on it is too low, and I'm not sure if it allows multiple devices. sndiod's 
backend can be enabled by service sndiod start: it is in /usr/local/etc/rc.d/.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Sid]

> blubee blubeeme - Tue Dec 5 00:48:05 UTC 2017

> If I can provide OSS audio/midi input and output for the tools that I use,
> then I can do all the routing natively with OSS.

I glossed over this in my response.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Sid]

> I prefer simplicity over complexity,
All ports and packages should be built with audio/sndio and audio/portaudio 
(not pulseaudio) as default for the front end to the FreeBSD's native OSS 
backend.

> I want the best possible audio for my system. I work with synthesizers and
> audio programs a lot and on Linux for pro audio everyone recommended using
> Jack sound server, which was always a pain to maintain, keep connections
> between sessions, etc...

> After learning more about audio, I realized that Jack only complicated
> things and OSS can do what jack without needing the additional complexity
> of Jack server.

> If I can provide OSS audio/midi input and output for the tools that I use,
> then I can do all the routing natively with OSS.

I thought Jack was a necessity for MIDI instruments and professional music 
production. If you say OSS can do it, then that's great.
sndio, and sometimes portaudio, is often required as a frontend, in order to 
replace ALSA and other complicated sound architectures.

> I ran osstest on my system and I was shocked how great my
> sound system is
This is what they commonly say about SNDIO and PORTAUDIO over FreeBSD's native 
version (/driver) of OSS.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[blubee blubeeme]

I'm taking a look at soundcard.h in /usr/include/sys/soundcard.h in FreeBSD
vs the soundcard.h in the offical OSS 4.01
https://sourceforge.net/p/opensound/git/ci/master/tree/include/soundcard.h

It seems like there's been a lot of changes between FreeBSD 3.8ish version
and the 4.0 version.

I was grepping around to see if any other files included this soundcard.h
header and if updating to the latest would break any other programs.

Is there anyone here who actively work on OSS have a moment for a few
questions?

On Tue, Dec 5, 2017 at 8:48 AM, blubee blubeeme <gurenc...@gmail.com> wrote:

> For me the why is simple.
>
> I want the best possible audio for my system. I work with synthesizers and
> audio programs a lot and on Linux for pro audio everyone recommended using
> Jack sound server, which was always a pain to maintain, keep connections
> between sessions, etc...
>
> After learning more about audio, I realized that Jack only complicated
> things and OSS can do what jack without needing the additional complexity
> of Jack server.
>
> If I can provide OSS audio/midi input and output for the tools that I use,
> then I can do all the routing natively with OSS.
>
> this: https://static.lwn.net/images/2013/audio-session/3-
> non-session-manager.png
> is what some audio setup looks like, then you have jack in the background
> like this: http://libremusicproduction.com/sites/default/files/articles/
> Qjackctl.png
>
> It almost never works if you try to save a session and restore it,
> something always breaks and that just ruins any motivation I had to
> continue a music project.
>
>
>
> This: http://manuals.opensound.com/developer/ossapi.html
> gives basically the same overview you provided above.
>
> Another reason why is because I prefer simplicity over complexity, sure
> FreeBSD sound is feature compatible with 4Front OSS but at the same time
> everyone is always saying how FreeBSD is short on developers but want to
> fork of an actively developed and maintained project? https://sourceforge.
> net/p/opensound/git/ci/master/tree/
>
> Why not let them keep on working on the project and pull that in so that
> we can always stay on top of what they are doing? Does FreeBSD have enough
> manpower to fork and maintain the project?
>
> I know one thing, I ran osstest on my system and I was shocked how great
> my sound system is, for the past year the audio has always been tinny and
> weird but now I am moving to make OSS my default audio driver and work in
> support for all the apps/ tools that I use.
>
> So that's why i'd like to have the official 4Front OSS drivers instead of
> a fork.
>
>
> On Tue, Dec 5, 2017 at 12:26 AM, Jan Beich <jbe...@freebsd.org> wrote:
>
>> blubee blubeeme <gurenc...@gmail.com> writes:
>>
>> > On Mon, Dec 4, 2017 at 8:08 PM, Jan Beich <jbe...@freebsd.org> wrote:
>> >
>> >> blubee blubeeme <gurenc...@gmail.com> writes:
>> >>
>> >> > I'm looking at the information for audio/oss and it seems that the
>> source
>> >> > used is different than the 4frontversion.
>> >> >
>> >> > -
>> >> >
>> >> > This port uses installation procedure that is very different from
>> >> > the one used by 4Front and is not supported by them.
>> >> >
>> >> > -
>> >> >
>> >> > The port also seems to lack a maintainer but a lot of work is being
>> >> > committed by  jbe...@freebsd.org, m...@freebsd.org and a few others.
>> >>
>> >> Well, you've answered your own question. There's no maintainer to check
>> >> which downstream differences still make sense.
>> >>
>> >> What is better maintained[1] and supported is FreeBSD fork of OSS -
>> >> sound(4).
>> >> See OSSv4 compatibility in https://people.freebsd.org/~
>> >> ariff/SOUND_4.TXT.html
>> >> Not sure why those bits haven't migrated into the manpage.
>> >>
>> >> [1] 4Front vs. FreeBSD commit activity:
>> >> https://sourceforge.net/p/opensound/git/ci/master/log/
>> >> https://svnweb.freebsd.org/base/head/sys/dev/sound/?view=log
>> >>
>> > Thanks for the heads up, I am still learning my way around so I might
>> ask
>> > questions that don't seem to make sense sometimes.
>> >
>> > Since there is no maintainer and the FreeBSD OSS is a fork [I'd assume]
>> of
>> > an earlier version, wouldn't it be wise to port over the new OSS 4.xx
>> since
>> > this page: http://manuals.opensound.com/developer/ossapi.html
>> > lists a lot of benefits for the new 4.xx version.
>>
>> Why? Not much of 4Front code is left[1] in FreeBSD implementation and
>> OSSv4 API is already supported.
>>
>> Please, be more specific what exactly you're missing.
>>
>> [1] See https://wiki.freebsd.org/Sound and copyrights under sys/dev/sound
>>
>
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[blubee blubeeme]

For me the why is simple.

I want the best possible audio for my system. I work with synthesizers and
audio programs a lot and on Linux for pro audio everyone recommended using
Jack sound server, which was always a pain to maintain, keep connections
between sessions, etc...

After learning more about audio, I realized that Jack only complicated
things and OSS can do what jack without needing the additional complexity
of Jack server.

If I can provide OSS audio/midi input and output for the tools that I use,
then I can do all the routing natively with OSS.

this:
https://static.lwn.net/images/2013/audio-session/3-non-session-manager.png
is what some audio setup looks like, then you have jack in the background
like this:
http://libremusicproduction.com/sites/default/files/articles/Qjackctl.png

It almost never works if you try to save a session and restore it,
something always breaks and that just ruins any motivation I had to
continue a music project.



This: http://manuals.opensound.com/developer/ossapi.html
gives basically the same overview you provided above.

Another reason why is because I prefer simplicity over complexity, sure
FreeBSD sound is feature compatible with 4Front OSS but at the same time
everyone is always saying how FreeBSD is short on developers but want to
fork of an actively developed and maintained project?
https://sourceforge.net/p/opensound/git/ci/master/tree/

Why not let them keep on working on the project and pull that in so that we
can always stay on top of what they are doing? Does FreeBSD have enough
manpower to fork and maintain the project?

I know one thing, I ran osstest on my system and I was shocked how great my
sound system is, for the past year the audio has always been tinny and
weird but now I am moving to make OSS my default audio driver and work in
support for all the apps/ tools that I use.

So that's why i'd like to have the official 4Front OSS drivers instead of a
fork.


On Tue, Dec 5, 2017 at 12:26 AM, Jan Beich <jbe...@freebsd.org> wrote:

> blubee blubeeme <gurenc...@gmail.com> writes:
>
> > On Mon, Dec 4, 2017 at 8:08 PM, Jan Beich <jbe...@freebsd.org> wrote:
> >
> >> blubee blubeeme <gurenc...@gmail.com> writes:
> >>
> >> > I'm looking at the information for audio/oss and it seems that the
> source
> >> > used is different than the 4frontversion.
> >> >
> >> > -
> >> >
> >> > This port uses installation procedure that is very different from
> >> > the one used by 4Front and is not supported by them.
> >> >
> >> > -
> >> >
> >> > The port also seems to lack a maintainer but a lot of work is being
> >> > committed by  jbe...@freebsd.org, m...@freebsd.org and a few others.
> >>
> >> Well, you've answered your own question. There's no maintainer to check
> >> which downstream differences still make sense.
> >>
> >> What is better maintained[1] and supported is FreeBSD fork of OSS -
> >> sound(4).
> >> See OSSv4 compatibility in https://people.freebsd.org/~
> >> ariff/SOUND_4.TXT.html
> >> Not sure why those bits haven't migrated into the manpage.
> >>
> >> [1] 4Front vs. FreeBSD commit activity:
> >> https://sourceforge.net/p/opensound/git/ci/master/log/
> >> https://svnweb.freebsd.org/base/head/sys/dev/sound/?view=log
> >>
> > Thanks for the heads up, I am still learning my way around so I might ask
> > questions that don't seem to make sense sometimes.
> >
> > Since there is no maintainer and the FreeBSD OSS is a fork [I'd assume]
> of
> > an earlier version, wouldn't it be wise to port over the new OSS 4.xx
> since
> > this page: http://manuals.opensound.com/developer/ossapi.html
> > lists a lot of benefits for the new 4.xx version.
>
> Why? Not much of 4Front code is left[1] in FreeBSD implementation and
> OSSv4 API is already supported.
>
> Please, be more specific what exactly you're missing.
>
> [1] See https://wiki.freebsd.org/Sound and copyrights under sys/dev/sound
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Jan Beich]

blubee blubeeme  writes:

> On Mon, Dec 4, 2017 at 8:08 PM, Jan Beich  wrote:
>
>> blubee blubeeme  writes:
>>
>> > I'm looking at the information for audio/oss and it seems that the source
>> > used is different than the 4frontversion.
>> >
>> > -
>> >
>> > This port uses installation procedure that is very different from
>> > the one used by 4Front and is not supported by them.
>> >
>> > -
>> >
>> > The port also seems to lack a maintainer but a lot of work is being
>> > committed by  jbe...@freebsd.org, m...@freebsd.org and a few others.
>>
>> Well, you've answered your own question. There's no maintainer to check
>> which downstream differences still make sense.
>>
>> What is better maintained[1] and supported is FreeBSD fork of OSS -
>> sound(4).
>> See OSSv4 compatibility in https://people.freebsd.org/~
>> ariff/SOUND_4.TXT.html
>> Not sure why those bits haven't migrated into the manpage.
>>
>> [1] 4Front vs. FreeBSD commit activity:
>> https://sourceforge.net/p/opensound/git/ci/master/log/
>> https://svnweb.freebsd.org/base/head/sys/dev/sound/?view=log
>>
> Thanks for the heads up, I am still learning my way around so I might ask
> questions that don't seem to make sense sometimes.
>
> Since there is no maintainer and the FreeBSD OSS is a fork [I'd assume] of
> an earlier version, wouldn't it be wise to port over the new OSS 4.xx since
> this page: http://manuals.opensound.com/developer/ossapi.html
> lists a lot of benefits for the new 4.xx version.

Why? Not much of 4Front code is left[1] in FreeBSD implementation and
OSSv4 API is already supported.

Please, be more specific what exactly you're missing.

[1] See https://wiki.freebsd.org/Sound and copyrights under sys/dev/sound
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[blubee blubeeme]

Thanks for the heads up, I am still learning my way around so I might ask
questions that don't seem to make sense sometimes.

Since there is no maintainer and the FreeBSD OSS is a fork [I'd assume] of
an earlier version, wouldn't it be wise to port over the new OSS 4.xx since
this page: http://manuals.opensound.com/developer/ossapi.html
lists a lot of benefits for the new 4.xx version.


On Mon, Dec 4, 2017 at 8:08 PM, Jan Beich  wrote:

> blubee blubeeme  writes:
>
> > I'm looking at the information for audio/oss and it seems that the source
> > used is different than the 4frontversion.
> >
> > -
> >
> > This port uses installation procedure that is very different from
> > the one used by 4Front and is not supported by them.
> >
> > -
> >
> > The port also seems to lack a maintainer but a lot of work is being
> > committed by  jbe...@freebsd.org, m...@freebsd.org and a few others.
>
> Well, you've answered your own question. There's no maintainer to check
> which downstream differences still make sense.
>
> What is better maintained[1] and supported is FreeBSD fork of OSS -
> sound(4).
> See OSSv4 compatibility in https://people.freebsd.org/~
> ariff/SOUND_4.TXT.html
> Not sure why those bits haven't migrated into the manpage.
>
> [1] 4Front vs. FreeBSD commit activity:
> https://sourceforge.net/p/opensound/git/ci/master/log/
> https://svnweb.freebsd.org/base/head/sys/dev/sound/?view=log
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Jan Beich]

blubee blubeeme  writes:

> I'm looking at the information for audio/oss and it seems that the source
> used is different than the 4frontversion.
>
> -
>
> This port uses installation procedure that is very different from
> the one used by 4Front and is not supported by them.
>
> -
>
> The port also seems to lack a maintainer but a lot of work is being
> committed by  jbe...@freebsd.org, m...@freebsd.org and a few others.

Well, you've answered your own question. There's no maintainer to check
which downstream differences still make sense.

What is better maintained[1] and supported is FreeBSD fork of OSS - sound(4).
See OSSv4 compatibility in https://people.freebsd.org/~ariff/SOUND_4.TXT.html
Not sure why those bits haven't migrated into the manpage.

[1] 4Front vs. FreeBSD commit activity:
https://sourceforge.net/p/opensound/git/ci/master/log/
https://svnweb.freebsd.org/base/head/sys/dev/sound/?view=log
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

OSS Audio

[blubee blubeeme]

I'm looking at the information for audio/oss and it seems that the source
used is different than the 4frontversion.

-

This port uses installation procedure that is very different from
the one used by 4Front and is not supported by them.

-

The port also seems to lack a maintainer but a lot of work is being
committed by  jbe...@freebsd.org, m...@freebsd.org and a few others.

Why is this version of oss different than the 4front version?

I know in the past 4front went closed source but version 4.xx has been open
sourced again along with many improvements.

Is there any reason why this port can't or shouldn't move to the one
supported by 4front?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"