Audio Recording API

Creating a new one from scratch would mean application developers would need to support maybe three sound APIs initially (depending on how far they want their software to be used). That worries me a bit: do developers want to do this?

No, but perhaps the new API (limited to 16bit) could rely on SharedSound and SoundDMA on old systems. And that SharedSound and SoundDMA could rely on the new API on new systems.

So everyone would be happy.
(I’m perhaps not very clear. Sorry :) ).

…perhaps the new API (limited to 16bit) could rely on SharedSound and SoundDMA on old systems. And that SharedSound and SoundDMA could rely on the new API on new systems.

I’m not sure that’ll help – the underlying implementation doesn’t really matter for developers.

If I was developing a new app, then which API do I support? If I need the new features, it’ll be the new API – no question. But if I want to support older machines, why would I use the new API, since the old ones still work?

USB HAL interface can pull data off the buffer and put it into the USB stack’s buffer which then goes to the USB devices’ buffer.

Which is how SerialUSB works and it’s horrible – but that’s another story. With the interface I suggested All that would be required of a device driver is a swi to register a buffer fill/empty callback and a swi to supply information on the channels it supports. and a control swi A device could register any and all input or ouput channels it has. channel info could be a block of xml text. The audio manager can supply functions to interrogate the xml block. That way the device driver just needs to supply a block of text with its capabilities for each channel it registers.

So the device driver has a minimal interface an actual device always fills in its native format – it is up to the client to decide if it can use the channel.

I would write a usb audio module with that interface – if USB changes I would write it again. Existing Hal devices just need their interface changing to the new one.

so if you started by with an Audio Device Manager module

Take the guts out of SharedSound and make a mixer device with the new device api registering an output channel with a PCM 16 bit interface. Take the output from the mixer resizing it for the the channel chosen by the selector from the list of output channels registered with Audiodevice manager.

The implementation of sharedsound would change to use the new Audio manager it would select the 16 bit PCM interface.

So now you have all the existing apps working with a makeshift 16bit mixer and the user can select from all compatible hal output channels

Soundma can be changed to connect to hal via the new Audiodevice Manager.

So basically you get just change the implimentations of the current system to use the new. That makes all legacy programs work 16bit you’ve just revamped the interface. At this point I can write a USB audio back end and register a 16/24/32 bit PCM channel depending on the device. This would appear as a selection to the user and they can chose to use any compatible output channel so would have usb audio with legacy apps relatively easily. New apps can use the new api directly access any registered audio channel at any resolution.

At some point you replace the systemmixer with one that mixes 32bit and outputs the resolution of the selected device – it doesn’t affect apps. At that point everything will work up to 32 bits.

Whether all the flexibility is useful or not is as you say debateable but you could have supported apps register with the audio device manager and the user can select the device for the program. You may have a headset on and be watching youtube where the sound isn’t mixed – who knows what weird and wonderful thing people want to do. Whether the system is capable or using the flexibility is another moot point.

But if I want to support older machines, why would I use the new API, since the old ones still work?

Why would you use any extentions to the existing interface. At the very least adding devices becomes independent of the HAL system and ROOL

WRT a question asked upthread:

I’d certainly find it useful to be able to use more than one USB audio device at the same time. This enables the user to operate a USB ADC and a USB DAC symultaneously. Very useful for test purposes. e.g. for doing measurements on some audio kit.

Also useful if someone wants to play some audio out into some headphones whilst they are capturing their own singing or playing in synch.

HOWEVER I suspect only a small minority will want to do such things. Most people will simply want to ‘play audio’. And some will want to do something like use a USB ADC to capture a digital transfer of an old CD, cassette, or some other analogue material.

Thus having one device at a time would probably be fine for most users. But a minority would like having the ability to run two (or more!).

Bottom line IMV: We really need ONE device at a time to be supported. But more would be good. Having the ability to play/capture stereo at rates > 48k and depths >16 is the key.

And some will want to do something like use a USB ADC to capture a digital transfer of an old CD, cassette, or some other analogue material.

Ah, but surely for that you would want to monitor what was being recorded? Certainly to know when to correctly start and stop recording…plus sometimes one has to fiddle with settings to get a good recording (my EeePC was fine recording with additional bass boost, but it seems to swamp the ADC on the desktop PC).

We really need ONE device at a time to be supported.

For playback, yes. If it can support on-the-fly switching (like directing to Bluetooth headphones if switched on, for example ¹) then I would imagine for most use cases one device at a time would suffice.
For recording, however, not being able to have IN and OUT active together (and not necessarily joined, one might want to hear the output post-filter) would be a hardship.

Having the ability to play/capture stereo at rates > 48k and depths >16 is the key.

While I would agree that this should be in the spec (along with consideration for the likes of 5.1), how necessary is it that this be implemented in an audio system intended for domestic computers?
I would have thought, for many use cases, the ability to get some sort of sensible behaviour handling 44100Hz/16bit would be key.
The Iyonix can’t, the AC’97 spec defines 48kHz and not 44.1kHz, and as such a lot of audio drivers make a mess of realtime resampling CD audio to playback. If this could be supported natively on compatible hardware, it would make CD (real or sampled) playback quite a bit nicer, as well as numerous mp3s and streaming radio stations that also run at 44.1kHz…

¹ Selecting and switching output device isn’t the sound system’s problem; but being able to redirect output to a different device without shutting down and restarting everything may well be…

WRT monitoring a recording: Usually the user will have a monitor on the analog input to be able to hear what is being recorded.The recording software at the user level should have decent meters. FWIW that tends to be PPMs for serious work. If you look you can see I included these in the demo recorder I wrote for USB. So although it may be handy for the computer to record and playback (almost) symultaneously via USB it isn’t vital.

FWIW These days I use a Benchmark ADC and DAC, but I used to use a Scarlett 2i2 which provides its own monitoring when recoring. That a typical device that someone doing stereo recordings or transcriptions will use.

More generally: The reality is that these days it is routine for anyone with a keen interest in audio to record at least as 96k/24. This gives more head and elbows room to avoid clipping or sampling filter imperfections. And 96k/24 is often preferred by people with good hifi kit. (Although personally I then dither/shape down to 96k/16 having scaled the levels optimally.)

Given that Linux/Mac/Doze all these days support well above 48k/16, and so do most decent ADCs and DACs it would look silly to not cover this. And I’ve had no problems at all running 96k/24 and 192k/24 though my ARMX6 using the items developed by others. The hardware has no problem with it. We just need the system to deal with it.

BTW a lot of AV is now 24 bit or at least 20 bit which then needs 3 bytes per sample.

Yes, the Iyonix was crap in this respect. But there is no need at all for such a limit on USB. 96k/24 or 192k/24 isn’t a problem. Indeed, nor is 192k/32 because the usual mode for the USB2 DACs/ADCS is to use 4 bytes per sample with the ‘lowest’ as discardable padding after the transfer.

If someone wants to experiment, have a look at the demo recorders and players. I’ve done both RO and Linux (ROX) examples. You can find it here

http://www.audiomisc.co.uk/software/index.html

Its crap, but works and makes the point.

Colin: Is your player available? That has the advantage of playing flac. I never bothered to add that as I know my programming is rubbish.

At the risk of frightening people of – shame about the lack of response, a simple ain’t gona happen move on would do :-)

Alternative 2
=====

I think it can be simplified further.

If you go back to basics to see what you want to achieve you have

1) The user who wants to use program x with any device that will work with it.

2) The program that can only output certain formats ie a simple program to stream a wav file can only output wav file formats.

So the user wants to know what devices they can use with a particular program and to be able to select the appropriate one. the Device may only do 44100 16bit 2ch stereo but that doesn’t matter if the user wants to use it thats ok.

So the Audio device manager becomes a means of matching a program to a device it supports.

From the programming point of view we want programs and devices to be as easy to write as possible. eg we don’t want device drivers to have to implement interface features which don’t apply to the device.

From an audio driver perspective:
-———————————————

An audio driver registers a single function with the Audio Manager (AM) for each input output channel it has.

There would be a required set of reason codes for interfacing with the Audio Manager (AM)

The trick is each channel registered doesn’t have the same interface they have the interface of a specific Audio class so a mp2 player would have reason codes to play mp3’s a 2 channel PCM stereo stereo class would have reason codes to play 2 channel PCM stereo stereo. an output channel would have reason codes for an output stream an input channel would have reason codes for an input stream. Also the device only implements those class capabilities that are relevent to it.

The most important reason code would be a capabilities function which tells the device manager what the device can do and what functions it has and can be used to determine if the device is suitable for a program.

The 2 channel PCM audio output class could be specified as

channel_id - required
PCM 2 ch
description
output stream
resolution_16bit
resolution_24bit
resolution_32bit
resolution changer
frequency changer
frequency_44100
frequency_88200
frequency_48000
frequency_96000
frequency_19200
volume_up
volume_down
volume_mute

some are functions others are info.

An audio channel may have the following capabilities list

channel_id
PCM 2 ch
output stream
resolution_16bit
frequency changer
frequency_44100
frequency_48000

The driver would do nothing about capabilities it didn’t have

Channel ids are 16byte hmac_md5 hashes then programs are just handling 16byte arrays instead of variable strings. For USB the hash can include the location on the usb bus or serial number if available, where it is plugged in. whether it is input or output, what usb interface is used, basically any information which can be used to identify a specific channel so that the user can leave it plugged in and save it for use next time. The advantage of the hash function is any amount of data can be thrown at it to identify the device and it gets crunched down to 16 bytes. hmac_md5 is available through the mbedtls library and the AM can provide functions to use it.

From the application
======

The Application can then ask the AM to enumerate the devices which has the capabilities it needs

It provides the AM with the following list

PCB 2 ch
output stream

to get a list of compatible channels it can handle and whether they are in use or not.

When selecting a compatible channel from the AM the AM returns a handle to access a specific device.

The application can then ask the AM what options are available by passing the handle to the AM with a list of options it would like to see eg.

description
frequency changer
frequency_44100
frequency_88200
frequency_48000
frequency_96000
frequency_19200
volume_up
volume_down
volume_mute

The for the channel specified earlier AM returns with

frequency changer
frequency_44100
frequency_48000

So the app can use a frequency changer reason code with one of the frequencies listed but can’t use the volume up reason code.

The application can allow the user to choose the device from the list and as it indicated the inuse devices it gives the user the opportunity to force the use of a specific device.

To make things easy for the app the AM has a selector popup window available. The app supplies the list of needed capabilities and a window pops up with just channels with those capabilities for the user to chose from

An mp3 device would have a different class specification as would a mixer so an app can ask if any mp3/mixer channels are available and again the options are negotiated like the PCM class.

With that implemented you have a device driver which just implements its capabilities without wondering what it does about an interface that doesn’t quite fit, An app which just asks for devices it can handle and just uses functions returned from the feature negotiation.

From the Audio manager
======
The audio manager can provide services to the app to make writing code easier. It could change the sample size for pcm audio class channels so that bit resolution doesn’t matter, It could provide a BufferManager interface as invariably buffers are not filled in the interrupt context and the AM can provide the service to do that for you so you can fill from a callback for example, if you want to use it. This also allows direct use of an audio device from a usermode application for prototyping or whatever. I deliberately did not say use devicefs that has problems with using fileswitch like blocking while closing because the buffer can’t flush – it is best avoided.

Extendability
=====

Classes are trivially extendable – if more capabilities are wanted in a class specification just add them – the device doesn’t care and a legacy app doesn’t care it hasn’t asked for them
Adding classes is trivially extendable. Just specify a class for a mixer, mp3 decoder it will all be ignored by apps that are not interested.

Fitting it to riscos
====

After the above was implemented. All audio devices are converted to the new backend api – just implementing the features it has and listing them in the capabilities list.
sharedsound and SoundDMA become applications to the new AM they have capability needs of

PCB 2 ch 
output stream

a configure plugin uses the AM channel selector window to allow the user to pick a channel for sharedsound from the list of devices that have sharesound capabilities

So all current apps work as now but users can use any compatible audio channel. DigitalCD for example could offer the choice of staying with Sharedsound or using a device direct with the same capabilities as sharedsound. A 32bit mixer could be added later if wanted.

Audio input.
====

Just add a input class specifying capabilities of input devices and the input channel can be registered with the manager available for use.

Jim. IsocPlayer

@Colin – That sounds very sensible and flexible to me. It would be great to be able to make full use of the sound capabilities of the hardware (and whatever additional hardware gets plugged in). Hopefully this will be across as much of the hardware platforms as it is possible to support, not just RasPi.

It is entirely reasonable to want one audio input device and one audio output device to work simultaneously. But is there a good enough reason to support more than one output device, or more than one input device, simultaneously? I think not.

I can see the importance of multiple synthesised sound sources being mixed, for playing music. Add in a system beep too.

WRT monitoring a recording: Usually the user will have a monitor on the analog input to be able to hear what is being recorded.

Yeah… you’re giving away the fact that you are not an average user.

The average user will have a turntable or walkman or something, which has a headphone jack. A cable between the device and the computer. And, of course, the expectation that the computer will be able to reproduce the sounds that it is recording.
Both Audacity and AudioGrabber can do this. Guess what I used to record some songs for mom…

The recording software at the user level should have decent meters.

You’ll find the meters tend to be colour coded (green, then yellow, then red) as the average person probably cannot read them, other than “green good, red bad”.

Plus, knowing how loud the recording is doesn’t tell you anything about how the recording sounds. Perhaps there’s a buzz because one of the plugs isn’t in all the way. Or maybe you need to restart the recording because your mobile phone spewed da-duh-da-duh-brrr-da-duh-da-duh in the middle of it?

BTW a lot of AV is now 24 bit or at least 20 bit which then needs 3 bytes per sample.

Just noticed, to stir things up a little, that the default recording setting in Audacity appears to be 44.1kHz 32bit float.

But is there a good enough reason to support more than one output device, or more than one input device, simultaneously? I think not.

2 output devices? Nothing comes to mind.
2 input devices? Well, karaoke perhaps? One input being a microphone and the other being music from somewhere? Admittedly, the number of people who would use RISC OS as a live karaoke recorder is quite likely a number extremely close to zero… ;-)

But is there a good enough reason to support more than one output device, or more than one input device, simultaneously? I think not.

One device will send to Bluetooth speaker. Another device sends output to computers own speakers.

The ‘average user’ may depend on who you are making your average over. However as far as I can tell the Scarlett 2i2 is about the most popular ADC people use and is both an ADC and a DAC with its own monitor. The point here is that we are discussing using USB audio, not a jack socket on the casework.

That doesn’t exclude someone else ensuring such a non-USB input works, even if it does a crappy job – like the old Iyonix.

FWIW the 2i2 I have is the original version. The current one is better. Goes to 192k/24 IIRC. It also has level indicator LEDs and you can monitor it.

Anyone with a record deck is going to need an amp, etc, to listen to it anyway. Thus can use that to monitor.

Audacity uses 32bit float internally IIRC as this minimises the risk of damaging the audio info when processing. You can therefore also work in this format. Even studios tend to record no more than 24 or 32 bit int because thats what ADCs tend to operate on. Thus in practice your main concern is to ensure that you record “pass the parcel” what the ADC outputs through USB. Even if the data is then going into Audacity. (Although personally I prefer to record direct 24 bit to a file to ensure this is pass the parcel.)

I don’t want to stop anyone from ensuring you can run an ADC and DAC in parallel to monitor IF it doesn’t hamper getting what is basically required. If it is easy enough, fine. But if we want RO to compete in terms of decent audio quality we will need the USB Audio working for both capture and playback. And devices like the 2i2 provide monitoring for the user.

IIRC even some of the cheap-as-chips Behringer ADCs provide a (headphones) monitor even though they have no level indicators.

The reality, though, with using the old-fashioned input socket on a computer is that it tends to be poor quality compared with even a modest USB device.

Colin: Thanks for adding the link to your player and for what you are doing.

This is how I see it working in practice

AudioMan swis
=============

swi AudioMan_MiscOp
Entry
    r0 = reason code
    r1 - rx reason code dependent
Exit
    r2 - rx reason code dependent    

Reason codes
------------

AudioMan_RegisterChannel         0
Entry:
    r0 = AudioMan_RegisterChannel
    r1 = 0 Register, 1 Deregister
    r2 = fn
    r3 = handle

Exit:
    none

AudioMan_GetChannelHandleById    1

Entry:
    r0 = AudioMan GetChannelHandleById 
    r1 = channel id;

Exit
    r0 = channel handle



AudioMan_EnumerateChannels       2

Entry:
    r0 = AudioMan_EnumerateChannels
    r1 = Capabilities list array ending in 0 of the capabilities to match
    r2 = more - 0 on first call, -1  when finished, handle set when more = -1
    
Exit:
    r2 = updated
    r3 = channel handle;



AudioMan_ChannelHasCapability    3

Entry:
    r0 = AudioMan_ChannelHasCapability
    r1 = channel handle
    r2 = Capability

Exit:
    r0 = 0 Doesn't have the capability



AudioMan_ChannelFunction         4

Entry:
    r0 = AudioMan_ChannelFunction
    r1 = channel handle
    r2 = Capability
    r3 - Capability dependant
    
Exit
    r0 - Capabilty dependant

AudioMan_RegisterChannel                0
AudioMan_GetChannelById                 1
AudioMan_EnumerateChannels              2
AudioMan_ChannelHasCapability           3
AudioMan_ChannelFunction                4

/* Capabilities */
    
/*
   Channel class. All channels are channel class.
   IdFn required by all channels.
 */
#define Channel_Class                   0x00
#define Channel_IdFn                    (Channel_Class + 0x01)
#define Channel_DescriptionFn           (Channel_Class + 0x02)

/* PCM 2 channel out class Specification */

#define PCM2ChOut_Class                 0x40
#define PCM2ChOut_RegisterBufferFillFn  (PCM2ChOut_Class + 0x01)
#define PCM2ChOut_Resolution16Bit       (PCM2ChOut_Class + 0x02)
#define PCM2ChOut_Resolution24Bit       (PCM2ChOut_Class + 0x03)
#define PCM2ChOut_Resolution32Bit       (PCM2ChOut_Class + 0x04)
#define PCM2ChOut_ResolutionChangerFn   (PCM2ChOut_Class + 0x05)
#define PCM2ChOut_Frequency44100        (PCM2ChOut_Class + 0x06)
#define PCM2ChOut_Frequency88200        (PCM2ChOut_Class + 0x07)
#define PCM2ChOut_Frequency48000        (PCM2ChOut_Class + 0x08)
#define PCM2ChOut_Frequency96000        (PCM2ChOut_Class + 0x09)
#define PCM2ChOut_Frequency192000       (PCM2ChOut_Class + 0x0a)
#define PCM2ChOut_FrequencyChangerFn    (PCM2ChOut_Class + 0x0b)
#define PCM2ChOut_VolumeUpFn            (PCM2ChOut_Class + 0x0c)
#define PCM2ChOut_VolumeDownFn          (PCM2ChOut_Class + 0x0d)
#define PCM2ChOut_VolumeMuteFn          (PCM2ChOut_Class + 0x0e)






/* Device driver function registered with AudioMan */

_kernel_oserror *channel_function(_kernel_swi_regs *reg)
{
    channel_t *channel = (void*) reg.r[1];
    switch (r->r[0])
    {
        case AudioMan_ChannelHasCapability:
            r->r[0] = 0;
            switch (r->r[2])
            {
                case Channel_IdFn:
                case Channel_DescriptionFn:
                case PCM2ChOut_Class:
                case PCM2ChOut_RegisterBufferFillFn:
                case PCM2ChOut_Resolution16Bit:
                case PCM2ChOut_Frequency44100:
                case PCM2ChOut_Frequency48000:
                case PCM2ChOut_FrequencyChangerFn: 
                    r->r[0] = 1;
                    break;
            }
            break;

         case AudioMan_ChannelFunction:
            switch (r->r[2])
            {
                case Channel_IdFn: return getid(reg);
                case Channel_DescriptionFn: return getdescription(reg);
                case PCM2ChOut_RegisterBufferFillFn: return registerbufferfill(reg);
                case PCM2ChOut_FrequencyChangerFn: return frequencychanger(reg);
            }
            break;
            
    }
    return NULL;
}

_kernel_oserror *module_init(...)
{
    foreach channel in channellist
        _swix(AudioMan_MiscOp,_INR(0,3),AudioMan_RegisterChannel, 0, 
                                            channel_fn_veneer, channel);
}

_kernel_oserror *module_final(...)
{
    foreach channel in channellist
        _swix(AudioMan_MiscOp,_INR(0,3),AudioMan_RegisterChannel, 1, 
                                         channel_function_veneer, channel);
}





/* Application usage */

int getChannelHandleById(char id[16])
{
    int handle;
    _swix(AudioMan_MiscOp,_INR(0,1) | OUT(0), AudioMan GetChannelHandleById, id, &handle);
    return handle;
}

int channelHasCapability(int channel_handle, int cap)
{
    int no = 0;
    _swix(AudioMan_MiscOp,INR(0,2) | OUT(0), AudioMan_ChannelHasCapability, channel_handle, cap, &no);
    return no;
}

int enumerateChannels(int* capability_array, int * more)
{
    int handle;
    _swix(AudioMan_MiscOp,_INR(0,2) | OUTR(2,3),AudioMan_EnumerateChannels, 
                     capability_array, more, &handle);
    return handle;
}

in main(void)
{
    int required_caps[] = { PCM2ChOut_Class,
                            PCM2ChOut_RegisterBufferFillFn,
                            PCM2ChOut_Frequency44100,
                            0
                          }

    int channel_handle = 0;
    int more = 0;
    while (more != -1)
    {
        channel_handle = enumerateChannels(required_caps, more);
        break;
    }
    
    /* alternatively if the channel id is known use getChannelHandleById() */
    
    if (channelHasCapability(channel_handle, PCM2ChOut_FrequencyChangerFn))
        _swix(AudioMan_MiscOp,_INR(0,3),AudioMan_ChannelFunction, channel_handle,
                              PCM2ChOut_FrequencyChangerFn, PCM2ChOut_Frequency44100);
                                       
    _swix(AudioMan_MiscOp,_INR(0,4),AudioMan_ChannelFunction, channel_handle,  
                             PCM2ChOut_RegisterBufferFillFn, fillfn_veneer, fillhandle);
    
                            
}

We just need the HAL audiodevice taken out of SoundDMA – a sort of HAL abstaction.

So we’ve identified two types of users: standard, and power users. We don’t want two APIs, but we also don’t want to overengineer something that isn’t going to be used.

The basic options for hardware support are:

1. Only one audio device being used at a time
2. More than one audio device playing the same stream at the same time
3. More than one audio device playing different streams at the same time

There’s probably no point in going to “two…”, because once you have more than one, you may as well make “many…”

Do we want arbitrary sample rates? Or just the “favourites”? (as mentioned above)

Supporting a small list would simplify playback/record code (although dropping support for 44.1KHz would make it even easier – but I suspect controversial!)

I’m not entirely convinced by the enumerations above – I would probably have a bit-field like arrangement, so bits 24..31 would be the class, 16..23 would be the ‘function’ (grouping?), and 0..15 would be a bit field. For example:

// Standard classes

// PCM2ChOut functions
#define PCM2ChOut_Resolution16Bit (Class_PCM2ChOut | Function_Resolution16Bit)
#define PCM2ChOut_Resolution24Bit (Class_PCM2ChOut | Function_Resolution24Bit)
#define PCM2ChOut_Resolution32Bit (Class_PCM2ChOut | Function_Resolution32Bit)
#define PCM2ChOut_Frequency44100 (Class_PCM2ChOut | Function_Frequency44100)
// And so on!

This would be a bit more compact, and easier to get what the capabilities are – although searching for a particular capability would be a little harder.

We’d need to consider what happens when we run out of something, and I was considering class-specific functions being 0×80..0xff.

A device would declare a list such as:

int mydetails[] = { Class_PCM2ChOut | Function_Resolution16Bit | Function_Resolution24Bit, Class_PCM2ChOut | Function_Frequency44100 | Function_Frequency88200, Class_PCM2ChOut | Function_ChannelCount2, 0 };

(Note: Not used to code formatting yet!)

If I need the new features, it’ll be the new API – no question. But if I want to support older machines, why would I use the new API, since the old ones still work?

Just to have one code for old and new computers.

So we’ve identified two types of users: standard, and power users. We don’t want two APIs, but we also don’t want to overengineer something that isn’t going to be used.

And for this too :)

Do we want arbitrary sample rates? Or just the “favourites”? (as mentioned above)

I would think that it might make sense to have provision in the specification for custom sample rates. But for what is actually implemented, stick to the common ones or it’ll never be finished. :-)

Oh, and…

although dropping support for 44.1KHz would make it even easier

…given it’s the official CD audio standard and all of my mp3s are encoded at this sample rate (using various different tools along the way – so I’m probably not alone) and YouTube uses 48kHz for Opus/WebM but 44.1kHz for M4A audio.
That sample rate isn’t going away any time soon.

so I’m probably not alone

Just checked, the ones I’ve bought from Amazon… my phone says they’re 44kHz.

I suppose one could’nt have 24bit samples used by older Progs.

Not used to code formatting yet

If your code has no blank lines put ‘bc. ’ – that’s a space after the . – at the beginning of the first line. If the code has a blank line in it use ’bc.. ’ – again space after the dot – at the beginning of the first line and ’p. ’ at the start of a normal paragraph after it.

With my system you can inherit other classes for example my PCM2ChOut_Class inherits the channel class. The channel class can be extended anytime with say DescriptionLong. Never have to worry about bit availability if for example an interface becomes deprecated,

With AudioMan_EnumerateChannels I can match capabilities for any class. I can add capabilities as tags. I can add a Hal class and have Hal devices use these codes I can then find a PCM2ChOut_Class,HAL_Class,HAL_Default. I can list HAL devices for people to pick a default device in the event that a device is unplugged. enumeraton is important as the capablitlies list will be used to filter the devices presented in a pop up window for users to select from.

Its trivial to implement – wrote the basic module in a couple of hours – 206 lines of code. swi code just looks like this.

_kernel_oserror *module_swis(int swi_offset, _kernel_swi_regs *r, void *pw)
{
    IGNORE(pw);
    switch (swi_offset)
    {
        case AudioMan_MiscOp - AudioMan_00:
            switch (r->r[0])
            {
                case AudioMan_RegisterChannel: return registerChannel(r);
                case AudioMan_GetChannelById: return getChannelById(r);
                case AudioMan_EnumerateChannels: return enumerateChannels(r);
                case AudioMan_ChannelHasCapability:
                case AudioMan_ChannelFunction:
                {
                    channel_t *channel = getChannel(r->r[1]);
                    if (channel == NULL) return err(E_NOSUCHCHANNEL);
                    r->r[1] = (int) channel->channel_handle;
                    return channel->channel_fn(r);
                }
            }
            break;
    }

    return error_BAD_SWI;
}