Under the hood, you’re using the Boomer audio subsystem. This is the kernel audio you’re using, and it only understands very simple PCM and ULAW formats. (ULAW is required for compatibility reasons; it’s a simple low quality format.) We tried hard to make it work well; I know some folks have had issues with skipping and noise artifacts, but I haven’t had enough data to be actionable (apart from inside VMs, which is definitely a more challenging target for audio support as the virtual audio devices implement an undocumented subset of the real ones.)
I’d actually like to see the Sun audioplayer and audiorecord utilities go the way of the dodo. They are really old and crufty, written in a quite old dialect of C++, and difficult to extend. There are vastly superior alternatives available, such as gstreamer based utilities, etc. It would be trivial to implement an audioplay / audiorecord workalike on top of those utilities. (The audiotest and audioctl programs are much newer — delivered with Boomer, and need to remain in order to test and control the underlying audio drivers and hardware, however.) The illumos-gate does not deliver any audio tooling other than audioplay, audiorecord (maybe audioconvert, I don’t recall?) audiotest, and audioctl. Apart from the last two, the other programs (and the library they share) should simply be punted from illumos-gate. It could be moved into a new consolidation in case some distro still wants them, but my guess is that most distros would be just fine without them, or would perhaps provide compatible alternative programs developed on top richer desktop audio subsystems like gstreamer. It’s kind of sad, but in truth boomer is sort of abandonware. Meaning I’m not working on it anymore, and I don’t know of anyone else that is. This is as much as or more from lack of demands as lack of interest on my part. Truthfully almost nobody uses illumos on the desktop/laptop, and for those that do the software we have (boomer wise) is normally adequate. - Garrett On Tue, Sep 26, 2017 at 8:27 AM John Howard <[email protected]> wrote: > I would like CELT integrated or plugged into Sun Audio player/recorder and > the AU format. CELT is better than proprietary MP3 and a considerable > innovation. Opus consists of CELT, Microsoft (Skype) SILK, and SILK + CELT > hybrid. SILK is designed for a congested Internet causing Realtime Audio > packet loss, which is irrelevant to non-Skypers. Safely ignore the hybrid > mode support and SILK. OPUS CELT is the current improved version and > sufficient for Realtime Audio play and record. I used Opus alot on FreeBSD > to record better-than-CD-quality audio. CELT is the best open source audio > codec available. > > In illumos I have only tested using the AudioHD device driver and the Sun > Audio player of the sample PCM AU files. Sounds great on my desktop PC. I > don't know what sound system is being used underneath. All the obsolete > telecom codecs supported by Sun AU should be removed, leaving only fast > paths for PCM and CELT handling. > > Another needed innovation is Dirac video codec accelerated by the GPU. > Dirac got a bad rap from a college kid writing a Signal/Noise Ratio > critique to graduate, and a publish-or-perish person trying to move up. > Its reputation was sabatoged before it got off the ground because it > competes with proprietary MPEG4. Dirac is the best open source video codec > available. Some specialized tweaks can make it even better. It is still > available from GStreamer despite its corporate abandonment. > > Heirloom Toolchest at SourceForge modernized Sun tools and Caldera tools > under the CDDL. Heirloom replaces many of the CLOSED BINS such as pax, od, > sed, tail, tr. Its troff tool produces excellent PDF with micro-typography > taken from TeX. Heirloom Unix commands can be used without interfering > with existing Unix commands (or GNU tools). All the Heirloom Tools were > upgraded to use UTF-8 and can be extended to use Big Endian UTF-32. This > changes the fundamental unit of Information Technology. It potentially > affects the design of Text Devices, and any program event loop. System > software and User software will be affected by it. > > Ideally, the Real Audio and Real Video and Real Text formats should be > upgraded with these three innovations to multimedia along with JPEG2000 > Real Image. Real Time Streaming Protocol using these formats is still > available from GStreamer despite widespread abandonment of the proprietary > Real Networks codecs in favor of MPEG4 and MP3. It is the proprietary Real > container format that is still useful. Their Helix project opens it to > future innovation. Here it is. > > -- John > > > On Thu, Sep 14, 2017 at 9:06 AM, Garrett D'Amore <[email protected]> > wrote: > >> Btw it would be possible to revert the timer driven audio and go back to >> using the device audio interrupts for some or all of the audio devices with >> only a modest amount of effort. It is also possible (likely) that just a >> little bit of adjustment to the audio tunables can be used to eliminate >> glitches. (There is a balance between latency and glitch-free audio - more >> buffering increases latency but may clear up any glitches. I selected >> values that I thought would give the best glitch-free audio with minimum >> latency but it is possible that in heavier workloads more buffering is >> needed.) >> >> On Thu, Sep 14, 2017 at 6:56 AM Garrett D'Amore <[email protected]> >> wrote: >> >>> >>> >>> Boomer isnt OSS and it isnt pulse. I havent worked on it in ages but >>> then I sort of assumed nobody was actually doing interesting things with >>> audio on illumos or Solaris. >>> >>> I partly suspect that some of the systems fare poorly with the timer >>> driven audio instead of using the on-chip isochronous interrupts. The >>> timer driven stuff was an innovation intended to facilitate moving audio >>> streams between different devices (especially SunRay stream mobility) and >>> also to make writing audio device drivers simpler. (No custom device >>> interrupt handling needed.) I know that this approach screwed up VMware as >>> their audio emulation actually depends on "using" the interrupts and cannot >>> run freely without them. I thought I fixed that. >>> >>> If folks have other audio issues I can perhaps try to look at it but I >>> would need solid problem reports and ideally access to some of the audio >>> devices that are affected. (I know USB audio support is a mess but that was >>> always the case even before boomer.) >>> >>> The current state of illumos audio may not be perfect but it is far >>> better than pre boomer days. (Recall that pre boomer the stack was dev >>> audio based and worked with few open source apps. It was a Sun specific >>> streams api. Boomer still supports that legacy api btw but also supports >>> OSS apis.) >>> >>> > *illumos-discuss* | Archives > <https://illumos.topicbox.com/groups/discuss/discussions/T83f198c8597cf8e3-Mc04d3f2d54c0a15f630e1ab9> > | Powered by Topicbox <https://topicbox.com> ------------------------------------------ illumos-discuss Archives: https://illumos.topicbox.com/groups/discuss/discussions/T83f198c8597cf8e3-M9742e1c830b382574ec3c257 Powered by Topicbox: https://topicbox.com
