Haven't been back here in years but just got a 17" G4 Power book for MorphOS 3.10. I have a ton of USB audio interfaces I can test: Tascam US-428, US-122, Pesounus USB, Focusrite 2i4, various other ones.

Quote:

Can you make a list with working devices ?

About differences between programs... it depends of the program if it'll use the Music Unit or Unit 0 (nothing usually defaults to any other unit). In some programs you can configure which unit to use, but not in all. In MPlayer, for example, there's the audio driver setting where you can select "ahi" for the Music Unit or "ahi_dev" for the Unit 0.

So when you're configuring AHI output to a different sound card, you have to take care that both the Music Unit and the Unit 0 are configured correctly. If your Music Unit is configured to use the Unit 0, it's enough to configure only the Unit 0 settings for the new sound card. But if you want to keep the Music Unit separated from the shared modes, then you have to configure both units separately.

In any case, if you're hearing audio from some program, then the actual card and its drivers are most likely working OK, and it's just an AHI configuration issue why you can't hear sound from all programs :)

[ Edited by jPV 12.04.2018 - 18:55 ]

@ jPV

It should be a great idea to have a tutorial about how to configure AHI in the MorphOS Library. Clearly, this is a confusing topic that would be deserving of easy-to-digest documentation.

Quote:

Yes, I'll report back here after I test them all. Maybe we should make a new thread with just post of hardware reports so folks don't have to shift through the bickering? :)



[ Edited by Spihunter 12.04.2018 - 13:16 ]

Many people seem to miss the point here.

Isochroous transfers have nothing to do with audio.

It is just a transfer protocol allowing loosing data during transfer. Mainly intended to be used for audio/video data transfers, where a lost data block simply is gone and cannot be resent. Unlike bulk transfers, which are used for massstorage, interrupt transfers which are for short burst data and control transfers which are for controling device features.

The audio driver included with MorphOS is based on the audio class standard setup during the early 2000 years, when USB came up. Thats why it is basically the same driver used as on other poseidon based systems. It may have gotten some minor changes in the past, but but basically it is the same driver you were/are using on 68K hardware, with High/Subway(??) and other cards.

Since then audio devices got more and more advanced. Back then the so called usb sound cards, were just used to output one pair of speakers. In very rare cases they got a microphone jack. These days they handle HDMI AV in/out and/or multiple other in and outputs and there are millions of devices out there and the standard probably got adapted to the needs (or abused due hacking additional features to them).

So blaming the MorphOS Team for enabling a feature that allows the usage of a gigantic amount of audio devices and even opens the door for creating a video class, so that current generation webcams can be handled, is kind of unfair due the fact that iso transfers are working.

You cannot blame the MorphOS team for every usb stick, every printer, every other hardware to fail, because it is simply impossible to guarantee anything. Even if Mr NonSense is bashing on every post.

Long story short. Back then MorphOS came with an audio usb class, which was useless due the lack of iso transfers. It got removed to avoid confusion and now since the hardware driver is supporting iso transfers it got reenabled. End of story.



[ Edited by geit 12.04.2018 - 21:37 ]

> Many people seem to miss the point here.

I don‘t think so.

> Isochroous transfers have nothing to do with audio. It is just a transfer protocol [...]
> Mainly intended to be used for audio/video data transfers

;-)

I got my Behringer uca-202 and unfortunately nothing is available as a recording input. I am hopeful this can be updated to allow at least a basic recording device like this to work. Tried the built in Audio Recorder and AudioEvolution4 but it seems the input is not recognized at all in AHI. 'monitor' 'gain' and 'input' all ghosted out. It's unfortunate but still can't record on emac/mini/laptops.

Quote:
If there is a Developer that will supply a postal address I have a spare one I can send for that Developer Team member to test out, and get the device to function correctly within MorphOS, to make its functionality work as expected - ideally with a volume control.

Ideally that someone would be in the UK, though I have no issue sending it to anywhere in Europe or USA/Canada, and I would pay for the postage/shipping to whoever needs it for that development - BUT ... after testing has been completed I'd expect it to be returned to me, ideally not at my expense.

Quote:
Following on from my previous remark, and one of the reasons that I made it, is that I should also mention now, as I forgot to mention it in thread #47 that after I had allocated the C-Media hardware in AHI, I used the device on one video file, and then before I could add/use/run/play another file the whole of my USB system "locks-up", my Bluetooth keyboard continues to function, but all my other USB hardware is "frozen", with usually follow-up warnings (PoPo messages) that USB devices have died/dropped-out one after the other, until they are all (probably) no longer allocated to my system. This has happened on more than one occasion, and the main reason for my reluctance at doing more testing on my own system, as I really feel this Isochronous implementation should have been made reliable/stable, and undergone far greater Developer Team/Beta-Tester team testing, before it was ever put into a system wide/main user release, as it has been with v3.10.

This USB sub-system failure, seems to me, only likely to be something to do with the Isochronous implementation affecting the whole of the USB Poseidon sub-system. In any case I have never had such a string of USB device failures until this issue with allocating an audio device that is an Isochronous device . . . co-incidental - I think not.

I know other users don't like to hear these words, but this release, IMHO, is . . . . well those of you who have read my posts about v3.10 release know what I think about it. I'm not saying it again - for now.

I've donated hardware before in order to help with its support, but I've never asked that it be sent back. Let alone at the developers expense.
So what is the encouragement for the developer to work on the problem?

Your warm and fuzzy personality?

Maybe you can afford to do so Jim, but I bought these devices to use with my Windows, Mac and MorphOS systems, as the device also has a built in SD/CF/FlashMem, 2 USB and audio (headphone/microphone) connectors, so it's not just some cheap and nasty bit of kit, it's really very useful, and I use it most days.

Previously with MorphOS I just used the 5 x memory card, and 2 x USB2 connector ports but if the audio is also made to work then that would be an additional feature, making it more useful, and something that I'd want back to be able to use myself, as probably no-one else will appreciate what a useful little adapter it is.

I was asked by Jacadcaps, if I'd donate it - and I seem to be the only one that's been asked to donate some hardware in this thread, but I'd be happy to loan it. I have put money into Bounties before and I will do so again, but I can ill afford to give-up this hardware, due to its usefulness to me personally, but I am prepared to make a temporary sacrifice, and if necessary I'll even pay for its return back to me, to improve the overall hardware capabilities of our OS . . . or should I be criticised for that too?

[ Edited by NewSense 13.04.2018 - 06:18 ]

Quote:
So which webcams work with this enabled USB Isochronous feature we now have?
Quote:
If you enable a feature, then surely it should have been tested with a range of hardware, to ensure there is not going to be this situation that I find my system in as a result of enabling it - or is that mine, a users fault for trying to see if it works, and I should have left it well alone, because this and that, and the other hasn't been tested, which Tcheko, and Zukow clearly indicated is the case, so it's not surprising that I've had such issues with it, and it should not have been released until it worked satisfactorily on a range of hardware, as that surely has got to be a minimum requirement to release any feature - well tested/stable. This, and some of the other main new features aren't that, sadly.

Don't think I enjoy saying this about this feature, or the other ones I have spoken about, as I, probably like most MorphOS users wanted it to work well, but I find this, and the printer system and the OWB release "well below par" for MorphOS previous standards, and I cannot understand why these features have been implemented as they only seem to be "half-baked". Can you honestly tell me that all these features work without issue on your own MorphOS system?

Quote:
Well, was there any need for that remark? I started this thread and the ones I have been "bashing on" about, due to either a lack of information in the release notes, a feature not working as intended/supposed to, or a backward step with a newer version of OWB.

I have spoken the truth, as hard as it may seem, but nothing more. This Isochronous feature, the new Printers feature, and v1.24 of OWB all work worse, or not at all, compared to what was in v3.9 release - or is that not the case for you too?
Quote:
I only started using/bought a key soon after MorphOS 3.1 was released, and I have, up until now, been mightily impressed with all the many features that it has. I also hope there are more to come, but I find no easy way of pointing out the shortcomings of these new features of MorphOS as they are so dire, incompatible, or just fail to work as intended - how can anyone say that "gently", especially when users have been waiting for 2+ years, and then this situation rears its head!!

I know you are now aware of these issues, and I am trying to temper my comments to suit the response, but I have not made any "personal" remark about anyone, but that cannot be said by others towards me . . . this is only due to me "bashing on" about the latest features not working - someone has to say it, and it seems no-one else wants to point out the actual truth of the situation. I am prepared to tell you the truth, but not many "vocalists" here, so far, seem to be prepared to face the truth of the situation. The sooner v3.11 comes along, and either these incomplete features are removed or fixed the better for all of us.

Quote:
Having a hard time with reading comprehension?

Quote:
Again, why should features be removed just because hardware YOU own doesn't happen to have drivers available? That's a pretty selfish and entitled attitude right there.

@NewSense:

Why should be removed?
If you don't like this feature, then don't use it.
Maybe others will find it useful. ;)

Quote:




Thanx Andreas, very useful explanation!

Quote:

Isochronous transfers are working fine. You could also blame Bulk transfers to be removed for each usb stick failed to work. Or interrupt transfers for every keyboard that is not working like expected.

Let me explain it like I would do to my ten year old nephew. ISO (as well as bulk, control and interrupt) transfers are wheels. And even with perfect wheels cars break down or fail to work.

So, if you somehow live in the real world and blame the wheels, when your car isn´t moving, then I am sorry. Maybe you are right and the world should fix the wheels first, before building cars.

Quote:

Well, you just proved what people here already were thinking. You even seem to miss reading my post. I go back under my rock waiting for 3.12.

Quote:

Come on. Don´t start playing stupid, too.

>>> Isochroous transfers have nothing to do with audio. It is just a transfer protocol [...]
>>> Mainly intended to be used for audio/video data transfers

>> ;-)

> Come on. Don´t start playing stupid, too.

Maybe, instead of using stupid car analogies, the facts would have been easier to grasp for the "many people" by admitting that isochronous transfer support indeed does have something to do with audio, but simply is a necessary yet insufficient feature when it comes to getting audio/video devices to work as they still need drivers, one of which has been included for basic and standard-compliant audio devices.

Quote:

On the plus side I was able to use the uca-202 on my ipad to record from vinyl and then transfer over to MorphOS via FTP for conversion to flac and copy to audio player. This will have to do until MorphOS can handle a simple 2x2 audio interface for direct recording. (playback seems to be working already) I guess no one bothered to update usbaudio class since isochronous transfers were not enabled until now.

Lexicon Alpha doesn't work. It shows up in Poseidon (with a mention of a firmware update in config?) but doesn't work quite right.

In AHI, I selected Lexicon Alpha 24 bit and loaded a sample into SoundFX. It did play, but was stuttering severely. When I clicked 'stop' MorphOS froze. Reboot. Tried the other Lexicon device listed in AHI (16 bit?) and got no sound.

I ordered an inexpensive Behringer audio device to try it out.

So still no audio recording with the Mac Mini for me.

(Off topic: The Lexicon Alpha works great on Android with Audio Evolution Mobile and the Davy's USB driver software.)

Quote:
That's very similar to my use of my C-Media USB audio adapter, and I get the same results with a Griffin iMic, stuttering audio with background noise, possibly data interference on the USB channel leaking into the audio channel, and then a system lockup when the USB audio device is de-activated.

So, what's the point of having the option to use a stuttering audio device that when it's de-activated in MorphOS/unplugged then causes the whole system to freeze/lockup? In it's current state it's a joke, and it shouldn't IMHO have been released until it was found to work correctly, and stably

You can, if you select a specific AHI channel for JukeBox be able to use the volume control built-into Jukebox, but surely it should be possible to use the master volume control for anything running through MorphOS, which this audio.class seems to be able to bypass.

Quote:
Another thing to consider by the Development Team - if fairly basic pieces of USB audio hardware work with other pieces of software we have access to but then doesn't work as it should be able to be expected to, then something is missing from the useability of this feature in MorphOS - these issues need fixing, as I have said all along. What is the point of implementing some feature, only to be unable to use it as it should be intended.

Betatesting in this case has either not been implemented or has failed us all badly, IMHO.

Quote:

Hmm. Releasing in its current state is a great way to get "so much more testing." I am happy about this. And thanks for testing and posting your results here. :)

I tried out USB audio support with a device which simply says "Sabrent" and has a headphone jack and input jack. It shows up in AHI as a device named "USB Audio Device????" but I cannot get any audio to come out of it.


Trident shows: Product ID: 20 (=0x0014)
Product version: 0100
Manufacturer: C-Media Electronics Inc.

Audio interface (0) shows bound to 1 (Audio Control)
but its audio interfaces (1) and (2) each show no binding.

FWIW, 3.10 has been the most stable version of MorphOS I've used so far on my Mac Mini G4. I have probably put in more hours on it already than any previous version.

Quote:

Yes, the audio issue still exists.

Quote:
I'd like to be able to agree with you, but I have had the situation under v3.10 where I've had a system lockup and as a result needed to reboot to get back to Ambient, with no HDD/devices shown on screen, or accessible on the system, and required a 30 second minimum cold-reboot to get my system to start correctly.

I've also had total system lockups with both SnoopDOS, and Snoopium, which occurred after a matter of only 20 seconds or so, after starting them running to try to work out a specific system call, which yet again required a 30 second cold-reboot in each instance.

These issues never happened under any earlier versions of MorphOS up to v3.9, but have happened ONLY when running v3.10.

I've had system fails under earlier versions of MorphOS, who hasn't? However, never of this nature, and with such fundamental parts of the OS, and as to what has caused them is a mystery to me at the moment, and a cause for concern.

3.11 fixes several issues with USB audio.

I've tested two USB Audio 2 Bluetooth dongles:

Anttus BT

and

Avantree Leaf

with the Leaf being a better option IMHO.

Both work and will let you use Bluetooth headphones with MorphOS.