The solution is to mix multiple audio sources together, in effect allowing /dev/sound (etc.) access to be non-exclusive for a single process but several ones instead. To make this happen, audio from those sources needs to be mixed to come out of the same speaker, and since data writte to /dev/sound gets inside the kernel, that is a good place to do the mixing.

Challenges in the play are if audio sources are of different quality (bitrate, stereo/mono, bitrate), so some adjusting may be needed. All this is met by the latest patch by Nathanial Sloss, see his posting to tech-kern for more information.

Also, note his request for review and testing! :-)

[Tags: audio, mixer, sound]

• In-kernel audio mixing: So far, NetBSD's audio device can only be opened once. If more than one application wants to play sound, the first one wins. This is suboptimal if you want to (say) play some MP3s but also get some occasional noise from your webbrowser.

  Now, Nathanial Sloss has made a stab at this, providing several implementation choices. Challenges in the task are that sounds with different quality (sampling rate, mono/stereo etc.) need to be brought to one common quality before mixing and passing on to the actual audio hardware. Further fun is added by the delay this process adds. See the discussion on tech-kern for all the gory details!

• Freescale i.MX7 support: Ryo Shimizu has committed support for the Freescale i.MX7 processor and the Atmark Techno Armadillo-IoT G3 board. according to his posting to port-arm (dmesg included), UART, Ethernet, USB, SDHC, RTC, GPIO, WDOG and MULTIPROCESSOR work. Interesting thing of the platform is that is has two Cortex-A7 cores and one Cortex-M4 core, the latter without MMU. Ideas on how to use the latter are welcome! :)

• PIE binaries with PaX, ASLR+MPROTECT are now the default for i386. ASLR and MPROTECT can be turned off either globally or per-binary if any problems should arise. Be sure to document those exceptions in your risk management! :-)

  More information: PaX, PIE, ASLR, MPROTECT.

• Platform improvements for i386 and amd64. For amd64, Maxime Villard writes:

   - I cleaned up the asm code and fixed several comments, which makes the
     boot process much easier to understand.
   - I fixed the alignment for the text segment, so that it can be covered by
     more large pages [1] - thereby reducing TLB contention.
   - I fixed a bug in the way the secondary CPUs are launched [2], which
     caused them to crash if they tried to access an X-less page.
   - I took rodata out of the text+rodata chunk, and put it in the data+bss+
     PRELOADED_MODULES+BOOTSTRAP_TABLES chunk [3]. rodata was no longer large
     page optimized, and had RWX permissions.
   - I retook rodata out of the rodata+data+bss+PRELOADED_MODULES+
     BOOTSTRAP_TABLES chunk, and made the kernel map it independently without
     the W permision [4].
   - I made the kernel map rodata without the X permission, by using the NOX
     bit on its pages [5] (now that the secondary CPUs could handle that
     properly).
   - I took the data+bss chunk out of the data+bss+PRELOADED_MODULES+
     BOOTSTRAP_TABLES chunk, and made the kernel map it independently without
     X permission [6].
   - I made the kernel remap rodata and data+bss with large pages and proper
     permissions [7] - which reduces once again TLB contention.
  

  See Maxime's posting to tech-kern for all the footnotes. Likewise, Maxime also tackled i386, and besides the changes from amd64, here is the list of changes from his email:

   - on non-PAE i386, NOX does not exist. Therefore the mappings all have an
     additional X permission. To benefit from X-less mappings, your CPU must
     support PAE, and your kernel must be GENERIC_PAE.
   - the segments are not large-page-aligned, which means that probably some
     parts of the segments are still mapped with normal pages. It is still more
     optimized than it used to be, but not as much as amd64 is.
  

$ rtunes - < /dev/pad0
$ mpg123 -a /dev/sound1 blah.mp3 

$ cat /dev/pad0 > blah.pcm''

To find out what /dev/sound* device to use, use dmesg(8) output - Jared tells me that ``/dev/soundN and /dev/audioN are the same device; the only difference is behaviour on open -- /dev/audioN emulates traditional Sun audio behaviour and resets the device to a known configuration, whereas /dev/soundN uses the previous device state.

There is nothing yet to discover the attachment apart from dmesg:

$ dmesg | grep pad0
pad0: Pseudo Audio Device
pad0: outputs: 44100Hz, 16-bit, stereo
audio1 at pad0: half duplex''