USBAudio and Mbox2

This device actually accepts the wav stream, but maybe it is the mixer stage that hasn’t been woken up, and the result is no livening of the panel leds and no sound output.
It is 5 years old, but the linux driver made it’s way into the kernel more recently at version 3.8 so perhaps that is an indication of the trickiness involved.
I’ve had a look at the previous replacement kernel driver, but apart from including a file with the output from lsusb, It doesn’t appear to have any documentation, and is not immediately apparent to where the changes to the alsa driver are.
Edit:
Inside quirks.c there is an initialising routine.

snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0),
/* Control magic - load onboard firmware */
0x85, 0xc0, 0x0001, 0x0000, &bootresponse, 0x0012);

Somehow I have to find a way to do this in BASIC.
Probably starting with the details of snd_usb_ctl_msg()
Is anyone familiar with those linux functions?

A quick google shows it to be a normal control request where:

bmRequestType = 0xc0
bRequest = 0×85
wValue = 0×0001
wIndex = 0×0000
wLength = 0×12

and bootresponse is a 18 byte buffer to receive the data. If you know about control requests the first 2 numbers being the wrong way around to the norm may have fooled you. If you rummage around my usb player you’ll find PROCcontrol which should do the job.

Have you tried Colin/Dave’s programs for probing the device, and my own probe program? If so, what results?

Jim

I have got the MBox 2 waking up with PROCcontrol and the prescribed bytes. I now have to proceed with setting rates as well because I am getting hiss mostly and sometimes a faint music track mixed with the hiss.
The device can do 48000 @ 24bits so I might have to set that back to 16bits and also 44100 a lot of the time.
The linux driver has:

static void mbox2_setup_48_24_magic(struct usb_device *dev)
746 {
747  u8 srate[3];
748  u8 temp[12];
749
750  /* Choose 48000Hz permanently */
751  srate[0] = 0x80;
752  srate[1] = 0xbb;
753  srate[2] = 0x00;
754
755  /* Send the magic! */
756  snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0),
757   0x01, 0x22, 0x0100, 0x0085, &temp, 0x0003);
758   snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0),
759   0x81, 0xa2, 0x0100, 0x0085, &srate, 0x0003);
760  snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0),
761   0x81, 0xa2, 0x0100, 0x0086, &srate, 0x0003);
762  snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0),
763   0x81, 0xa2, 0x0100, 0x0003, &srate, 0x0003);
764  return;
765  }

I am puzzling over the difference of the send and receive functions in relation to putting these bytes into PROCcontrol. Does ‘type’ change for send?
(usb_rcvcntrlpipe versus usb_sndcntrlpipe)
Note the change of the first two bytes.

It is good to be over the first hurdle, more will have to be done to check for the device id as a condition for running the routine.

 DIM bootresponse% 18
      ctr%=0
      ctr2%=0
      ?bootresponse%=0
    REPEAT
    PROCusb_control(192,133,1,0,18,bootresponse%)
       REPEAT
       ctr2%+=1
       UNTIL ctr2%=1000000
       ctr2%=0
    ctr%+=1
    UNTIL (?bootresponse%=2 OR ctr%=10)
    IF ?bootresponse%=2 PRINT "MBox 2 initialise success" ELSE PRINT "MBox 2 iniitialise failure:";$bootresponce%

Also I think there is a wimppoll method for getting a delay, rather than counting to one million.

snd_usb_ctl_msg maps to DeviceFS_CallDevice like this

SWI DeviceFS_CallDevice

r0 = (1<<31)
r1 = "USB8" - or whatever the device is
r2 = bmRequestType | (bRequest << 8) | (wValue << 16) 
r3 = wIndex | (wLength << 16)
r4 = data - data buffer pointer of length wLength
r5 = 0

snd_usb_ctl_msg(struct usbdev,
                insigned int pipe,
                _u8 bRequest,
                _u8 bmRequestType,
                _u16 wValue,
                _u16 wIndex,
                void* data,
                _u16 wLength)

The bmRequestType tells you the type of request and holds the direction

bit 7 is the data direction of the request
   0 - host to device
   1 - device to host
bits 5-6 type of request
   0 - Standard - ie usb requests applicable to all devices.
   1 - Class Specific - ie usb requests specific to a device class.
   2 - Vendor Specific - ie usb requests only known to the vendor.
bits 0-4 destination of the request
   0 - Device
   1 - Interface
   2 - Endpoint

So a bmRequestType of 0xA2 is a class specific request to read data from an endpoint. 0×22 is a Class specific write to an endpoint.

bRequest is the equivalent to the action code. For a class 1 audio device a request of 0×81 is a read current value action code (0×01 is write current value)

note The names I’m using correspond to the names used in the USB standards – it just avoids confusion to use these names.

The device can do 48000 @ 24bits so I might have to set that back to 16bits and also 44100 a lot of the time.

If you post a link to the output of usbdescriptors it’ll tell me the capabilities.

The reads of endpoints 0×85 and 0×86 in the linux drivers don’t seem to be serving any purpose.

756  snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0),
757   0x01, 0x22, 0x0100, 0x0085, &temp, 0x0003); //This writes the frequency to endpoint 0x85
758   snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0),
759   0x81, 0xa2, 0x0100, 0x0085, &srate, 0x0003); //This reads the frequency for endpoint 0x85
760  snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0),
761   0x81, 0xa2, 0x0100, 0x0086, &srate, 0x0003); //This reads the frequency for endpoint 0x86
762  snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0),
763   0x81, 0xa2, 0x0100, 0x0003, &srate, 0x0003); //This reads the frequency for endpoint 3

Different capabilities will probably need different alternate/endpoint settings.

I’ve had no luck by trying to mimic that 48000 setup stuff into PROCcontrol so far.
I noted that that setup made a temp array of 12 bytes then entered it’s length as 3. C must have coped with it.
here is the output from !USBDescriptors
http://homepages.woosh.co.nz/ron.may/MBox2Desc.txt
This is the lsusb decriptor that was included with the linux source.
http://homepages.woosh.co.nz/ron.may/mbox2lsusb.txt

Once the firmware has been installed, the device may perhaps look like a standard USB Audio device. If that’s the case, then using my USBAudio module should be far easier than what you’re trying to do.

The questions are whether RISC OS sees the device as an audio class device after the fimware installation, and whether the firmware is still in place after a USB Reset (which is what might be necessary to force RISC OS to enumerate the device again).

Dave, currently, after bringing the box to life with Colins Player, your player will only open with a 24bit
48000 wav. Unfortunately I just get an identical hiss on the output.
Colins player is accepting other formats and one type you can hear some audio mixed with the noise. It is erratic though.
Here is a snapshot of !USBInfo with full info.
http://homepages.woosh.co.nz/ron.may/usbinfo.png
This box has a midi in/out though I dont think there is an internal sound module for it, so it can’t be a mixer input.
The others are spdif in/out, left/right output, two mic inputs, two of each 1/4 jack ts/trs inputs.
My Linux box, pulse audio shows it as 1.1 root hub.
I guess it is referring to the computer one that is connected to it for some reason.

mbox2_setup_48_24_magic is rubbish. temp is just a buffer – the size is not significant as long as its >=3. The first snd_usb_ctl_msg writes the first 3 bytes of it to endpoint 0×85 and temp hasn’t been initialised. The last 3 snd_usb_ctl_msg are reading 3 bytes to srate when it should be writing the sample rate.

What you have is a device with 4 interfaces 2 output and 2 input. So what are you trying to do play or record? Interestingly one of the outputs is ac3 – never seen one of them before. You should be able to get that to work as well.

What you have is 4 interfaces and each interface can have a choice of alternate settings. So bInterfaceNumber 3 bAlternateSetting 6 is ac3 output. The choices you have are laid out below. What are you trying to do. play or record? I’d have expected my player to work on interface 2 – it picks the first that works. interface 4 and 5 should work with my recorder program.

bInterfaceNumber 2
	bAlternateSetting 2 - PCM 8000 to 48000 2ch 24bit asynchronous OUT endpoint (0x3 and 0x83)
	bAlternateSetting 3 - same as bAlternateSetting 2

bInterfaceNumber 3
	bAlternateSetting 2 - PCM 8000 to 48000 2ch 24bit asynchronous OUT endpoint (0x4 and 0x84)
	bAlternateSetting 3 - same as bAlternateSetting 2
	bAlternateSetting 6 - IEC1937_AC3 8000 - 48000 2ch 16bit synchronous OUT (0x4)
	
bInterfaceNumber 4
	bAlternateSetting 2 - PCM 8000 to 48000 2ch 24bit asynchronous IN endpoint (0x85)
	bAlternateSetting 3 - PCM 8000 to 48000 2ch 24bit synchronous IN endpoint (0x85)
	
bInterfaceNumber 5
	bAlternateSetting 2 - PCM 8000 to 48000 2ch 24bit asynchronous IN endpoint (0x86)
	bAlternateSetting 3 - PCM 8000 to 48000 2ch 24bit synchronous IN endpoint (0x86)

Thanks Colin, I will try some recording later, It looks like it must have 24bit 48000 for playback always.
Edit: wait a minute, 8000-48000 24bit, that sounds flexible.
The ac3 is usually sent in a wav container, I’ve only heard of 44100 or 48000 being used though. The box only has stereo analogue output, so it probably only makes sense to pass it through to spdif out. I suppose it’s possible that it can re-encode the surround down to stereo for use though.

There isn’t a sample frequency control for any of the PCM outputs. The ac3 output does have a frequency control.
So it looks like you are stuck with 48000 for PCM out unless either the device has a frequency control switch or the byte rate determines the frequency. I don’t think it likely that the byte rate determines frequency because the endpoints are asynchronous which means the byte rate is determined from a feedback endpoint ie the byterate is fine tuned by the device. It may be that the alternate 2 setting is 48000 and alternate 3 setting is 44100 that may explain why the interface has 2 identical looking alternates.

Do you have my player working at 48000?

For recording for the alternate 2 endpoint’s frequency is determined by byterate, alternate 3 endpoints do have a sample frequency control. There’s no need to use the alternate 3 setting. The alternate 2 setting should record at the byterate used – ie the samplerate used when opening the usb endpoint.

So to conclude there is no frequency controls to set – so mbox2_setup_48_24_magic was a waste of time as even if it did what it was trying to do it still wouldn’t do anything as there are no frequency controls.

I don’t think reading of bootresponse is relevant

/* Control magic - load onboard firmware */

suggests its for reading software from the device which won’t work anyway.

Looking at bInterfaceNumber 2 there are 3 alternate settings 2,3 and 6. This implies that the device has only a subset of a more comprehensive interface where alternate settings 1,4,5,6 exist for this interface. You can speculate that alternate settings 1 to 5 decide the PCM frequency and your device doesn’t have some of these alternate settings so can’t do those frequencies.

I am getting hiss mostly and sometimes a faint music

That sounds like its working but you are sending 16bit audio to a 24 bit endpoint – the device only does 24bit pcm.

I found another couple of versions of quirk.c I’ll put up the MBox 2 section as it has more comments.
http://homepages.woosh.co.nz/ron.may/different_quirks.txt
You are right, there was nothing working from $bootresponse%, and there is an error printed from the inbuilt function when one occurs anyway.
Edit: Checking ?bootresponse%=2 does stop the function from repeating the 10 times, usually after one or two.

I have been using INKEY 100 as a delay, but though the specified time works in interactive BASIC, in the program it seems to speed up.
I was able to get a recording session working, by using your map of interface, alternatives and endpoints, but no meaningfull audio yet. I haven’t found all my mics but have one feeding one channel straight through to the headphone, but I dont know if that means it can be picked up from all endpoints or just one. A similar amount of flexibility for selecting the output in the player would be good, but I think the lack of good technical documentation is the major problem. For example big endian is mentioned for 24bit, but does that mean all 48000 24bit is solely bigendian, It may be that it’s for early MAC’s bigendian AIF. There is 24bit bigendian on DVD’s, but that format may be newer than this box.

IsocPlayer2.zip is a pared down version of IsocPlayer where you have to set all the values explicitly for a particular device – like you do for IsocRecorder. ie it doesn’t find the device automatically.

I’ve made an entry at the top of the runimage for the mbox2 device – I’ve filled in the values for the first out interface does it work?

Things to try. changing bmAlternateSetting% to 3 or changing xSamplerate% to 44100 and using a 44100 24bit wav. You are trying to play 24bit PCM wav files aren’t you?

bInterfaceNumber% = 3 is the other audio out for the device.

Note it has xSetFrequency% set to 0 because you can’t set the frequency.

You have 2 stereo inputs and 2 stereo outputs all are independent of each other. If mixing is available it’s not done at the usb level.

If endianness is an issue I’ll pass on that for now.

Regarding quirks.txt I don’t see that it does anything useful except maybe waiting until the device is ready but if it wasn’t ready you wouldn’t have the usb descriptor list. It’s only reading data from the device which isn’t any use to you.

mbox2_skip_setting_quirk doesn’t do anything useful as far as I can see.

Yes, that player is doing everything you intended. I have noticed both old and new versions seem to leave the file open after escaping playing. I only noticed this when trying to move the file after ceasing playing it, and it possibly happens whenever escape is used.

This is the first time I’ve had a 24bit device so I have only one 24bit wave file so far.
Reading the MBox 2 introductory PDF It would seem that 44100 and 48000 at both 16 and 24 bits is the target range.
So far I’ve only heard faint music from a 16bit 48000 wav played at the 24bit setting, and even that fizzles out into noise after a few seconds.
I will need to produce a range of wav files with differing properties to try and find one that works.
The job is made difficult because sometimes the box loses it’s marbles, and noise stays after the playing has stopped, like the data can corrupt the system sometimes.
The new player will let me try a few things, even if the shots bounce off time to time.
Edit: I have converted a 48000 16bit wav to 24bit using !FFmpeg and pcm_s24le encoding but the player errors with “Not PCM (36) (11)”
sndfile-info seems to confirm that it is a wav file with pcm and the file starts with RIFF, haven’t looked further than this.
I fudged it to accept it and Hooray!!, it does play in clear stereo after a few seconds of settling down.
maybe the start of the file is incorrect.

Yes, that player is doing everything you intended

I’m glad you know what I intended. Does it play 48000 24bit?

I have noticed both old and new versions seem to leave the file open after escaping playing.

I can only think its a difference in the editor you use. I use srcedit – I doubt many other people do. Does running this basic program in a task window print HELLO when you press escape?

ON ERROR PRINT "HELLO":END
REPEAT UNTIL 0

If it plays 48000 24bit it will play 48000 16bit in the same endpoint. The 16bit values just need shifting to 24bit values. The assembler should do this for you and you shouldn’t need to change isocplayer2 for it to play 16bit.

Changing xSamplerate to 44100 and bAlternateSetting to 3 may play both 44100 24bit and16bit.

Yes, the problem is not to do with needing 24bit, it is that I have to ‘bump’ it into action, then the hiss changes to audio. All four formats work with the /only/ change needed being 44100 – 48000. in fact I dont think varying the 24bit setting has any effect, and it is possibly getting ignored in playback mode.
Now to the nitty gritty, By ’bumping the stream, I mean by way of a desktop/mouse disturbance. Currently I try to move the vertical slug in the edit taskwindow, and usually this is enough, sometimes a few attempts are required, or it can toggle back to hiss if twiddling to much on some tracks.
It is good that I have established the format to be common wav files, but the audio is not clean, there is a residual squelchy noise noticeable when it is not drowned out by the louder music.

I’ve found that changing interfaces/endpoints etc leads to needing a reset, so I haven’t done much with that yet, there will be others that do work judging by previous attempts with the hiss/noise following me around.

the problem is not to do with needing 24bit, it is that I have to ‘bump’ it into action

Try changing line 66 in Runimage from

A$ += ";size"+STR$(128*1024)

to

A$ += ";size"+STR$(xSampleSize% * xSampleRate% * 2)

If that doesn’t work does pressing f12 bump it into action when you return to the desktop? I suspect that the buffer is correcting itself after it is emptied. Using window furniture stops the program and allows the buffer to empty.

but the audio is not clean

Is it the same for all four formats?

I’m surprised that both 44100 and 48000 work to the same endpoint. The rate of data transfer is determined by the device (it’s an asynchronous endpoint) and I can’t see how it can know which sample rate you are sending. Even adaptive endpoints which use the data rate you send to determine the sample rate tend to only do so in a small window around its programmed samplerate. Are you sure the 44100 wave file isn’t being played slightly fast or the 48000 wave slightly slow?

I’ve found that changing interfaces/endpoints etc leads to needing a reset

Is that a computer reset or a device reset? Is it caused by Escape not working as expected if so just put

IF INKEY(-99) PROCfinish

after line 115

IF r3% > 0 SYS "OS_GBPB", write%, out%, r2%,r3% TO,,r2%,r3%

and Space should stop the music.

Does a simply USB device reset help make it work in the first place? If you’ve tried that I’ve missed the results.

Edit: I have converted a 48000 16bit wav to 24bit using !FFmpeg and pcm_s24le encoding but the player errors with “Not PCM (36) (11)” sndfile-info seems to confirm that it is a wav file with pcm and the file starts with RIFF, haven’t looked further than this.

FWIW You may find the port of sox more convenient for tasks like reshuffling, etc, LPCM audio.

There is also a program on my software page that will list any ‘extended’ or other chunks in the metadata of a wave file. IIRC Colin and Dave’s players/recorders are like mine and assume plain metadata. But your device may be up to something else for all I know.

I’m assuming from what you’ve said the format the device transfers/requires is s24. But class 2 devices may want / include padding bytes so the data is s32le with a zero least-significant byte.

The device is 24bit. There should have been no need to convert the 48000 16bit file my program does 16 – 24bit conversion on the fly.

Having a bigger subslotsize for a given bitrate eg 24bit audio played in a 32bit slot is not a class problem it’s just how the device is designed. It can occur in class 1 or class 2 devices. In this case 16 bit files are played in a 24bit slot so need padding out.

On another issue, I have a webcam that may interest you Jim. The audio is class 1 on a high speed (USB2) device showing that class 1 isn’t limited to full speed (usb1) devices.

Hi Colin,

Thanks. Afraid I’ve not followed all the previous discussion, so wasn’t clear on the problem.

Interesting about the webcam. With that situation would it mean that 192k/16 stereo could be exceeded? Or is that tied
into the way the transfers because of the set time between transfers and max bits per transfer exchange? i.e. is the limit
hardware based so class 1 doesn’t try to beat it? Or protocol timing/allocation based?

Cheers,

Jim

With that situation would it mean that 192k/16 stereo could be exceeded?

Depends on how you interpret the standard. Personally I think it’s been stretched to work on USB2 – I had to modify the usb module to make it work. I can understand why it was done. You upgrade a video interface of a device to USB2 and already have class 1 software for the microphone. So what they’ve done is change the interval that audio data is read from the device to 1 in every 8 frames instead of every frame. USB2 has 8000 frames per sec USB1 1000 frames per sec. If this is proper use then yes class 1 could have higher res audio.

Interested in the ‘rate cap’ because two devices I have are class 1 and limited by this.

In each case the designer would have liked a higher data rate but decided they had
to stick within the USB1/class 1 limits. 192k/16 in one case, 96k/24 in the other.
Both have internal hardware that can do 192k/24 but can’t transfer it.

In both cases they’ve told me a main reason for this was in essence: “Windows only does class 1
by default and I wanted to avoid getting into supplying a driver.”

The problem, I guess, is that they can’t tell what hardware the device will
be connected via.

Thanks. I’ll duck out and let the thread get back on topic! :-)

Jim

Jim, FWIW I used ffmpeg on linux and got the same ‘Not PCM’ error with both Colin’s and Daves players. I had a quick look at sox and the command line —help didn’t make it clear how to do it, and I didn’t have the HTML help handy. But I wont be doing any converting now that I know 16bit tracks play straight off, and I have moved on.

Colin, I timed a track playing at 44100 then 48000 and got close to the same ratio of 48000:44100 so I can definitely say that the speed can be changed /without/ endpoint changes. I did notice the difference in the pitch but now it is verified.

Using your xSamplesize% * xSamplerate% * 2 gave silence rather than a hiss that can be bumped, but sometimes silence means a reset is needed so I’ll check again. I tried a variety of sizes there and some lock me out from bumping some dont. On one occasion when it was set at 4096*8 it started straight off by itself, the only time that has happened, and I couldn’t repeat it.
Edit: I have found 4096*20 to give the easiest bump starting across the four formats.
Further desktop activity can bump it out of sync again.
There typically is three modes to cycle through one of them being the desirable one.

When things go completely quiet, It doesn’t necessarily mean any settings are wrong until replugging/resetting the usb box and checking again.
Edit: resetting the box still got silence but changing to 44100 and get a bit of noise, but it is still one of those sizes where I can’t bump it into playing properly. Maybe the larger the noise, the closer it is to going by itself (-:

The low end noise is there the same on all four formats, It seems to be only there when the audio signals are there. When a track has ended it drops to a quiet hiss which would be normal line/psu noise I think. My rj45 usb extender can quieten that, but I found the necessary ‘bumping’ doesn’t work when it is in use.
On lineout/external amp/speakers the low end accompaning noise is barely noticeable,
I think I should make some comparisons to Linux playing the MBox 2 to verify that it is our USB causing it.