Author Topic: Updated Uniaud32 build  (Read 42626 times)

David McKenna

  • Sr. Member
  • ****
  • Thank You
  • -Given: 12
  • -Receive: 25
  • Posts: 331
  • Karma: +13/-0
    • View Profile
Re: Updated Uniaud32 build
« Reply #510 on: January 19, 2021, 12:17:51 pm »
 Hi Paul,

  Don't see anything like that in my alsahlp$ log, but maybe you can spot the right message? Alsahlp$ attached...

Regards,

Paul Smedley

  • Hero Member
  • *****
  • Thank You
  • -Given: 57
  • -Receive: 110
  • Posts: 809
  • Karma: +50/-0
    • View Profile
Re: Updated Uniaud32 build
« Reply #511 on: January 19, 2021, 02:06:52 pm »
Sorry, needs a debug driver....

Ian Manners

  • Global Moderator
  • Sr. Member
  • *****
  • Thank You
  • -Given: 49
  • -Receive: 32
  • Posts: 400
  • Karma: +5/-0
  • I am the computer, it is me.
    • View Profile
    • ComKal Networks Australia
Re: Updated Uniaud32 build
« Reply #512 on: January 19, 2021, 03:39:06 pm »
Sorry, needs a debug driver....

Yep, I also figured that out on the 2nd card swap when I realised the logs didn't have much :o)
Lots of streams for you after I also swapped to the debug version :)
One Audigy card (Audigy SE [SB0570]) not checked as its in another computer at present.
Cheers
Ian B Manners

David McKenna

  • Sr. Member
  • ****
  • Thank You
  • -Given: 12
  • -Receive: 25
  • Posts: 331
  • Karma: +13/-0
    • View Profile
Re: Updated Uniaud32 build
« Reply #513 on: January 19, 2021, 11:33:59 pm »
Sorry, needs a debug driver....

 Ah... I should have known. Both my desktop (HDA:ALC887-VD) and laptop (HDA:IDT 92HD81B1X5) have 3 instances of something like this:

GetUniaudPcmCaps: cp1. pcm 0, phandle f00a8af8
GetUniaudPcmCaps: pcm 0, cp2. nr of streams: 1
chan: from 2 to 2

 So 1 stream... Bummer City!

 Can stream mixing be added to the driver or does it need to be implemented thru MMOS/2 (if at all)?

Regards,

Neil Waldhauer

  • Hero Member
  • *****
  • Thank You
  • -Given: 12
  • -Receive: 52
  • Posts: 683
  • Karma: +3/-0
    • View Profile
    • Blonde Guy
Re: Updated Uniaud32 build
« Reply #514 on: January 20, 2021, 01:12:13 am »
https://smedley.id.au/tmp/uniaud32-linux-5.10.7-20210117.zip - just code cleanups - shouldn't change any behaviour....

This build produces sound output on my Lenovo ThinkCentre M720s with the following sound card built-in.

Command line mixer for UNIAUD32. Version 1.1
Detected UNIAUD version 3.01.01
Detected 1 audio adapter(s)
Card info for adapter 0:
  num: 0
  id: PCH
  driver: HDA-Intel
  name: HDA Intel PCH
  longname: HDA Intel PCH at 0xb1230000 irq 16
  mixer: Realtek ALC233
  componenets: HDA:10ec0235,17aa312a,00100002 HDA:8086280b,80860101,00100000

Line out makes sound. The volume control works.
Speaker does not make sound.
Microphone was not tested.

PMUniMix shows 5 volume controls: master volume and line-out volume work.

unimix - list shows 29 controls
Expert consulting for ArcaOS, OS/2 and eComStation
http://www.blondeguy.com

Paul Smedley

  • Hero Member
  • *****
  • Thank You
  • -Given: 57
  • -Receive: 110
  • Posts: 809
  • Karma: +50/-0
    • View Profile
Re: Updated Uniaud32 build
« Reply #515 on: January 20, 2021, 03:11:41 am »
Hi Dave,
Can stream mixing be added to the driver or does it need to be implemented thru MMOS/2 (if at all)?

I don't know yet. In my head I'm thinking it would need to be a layer in between uniaud16 and uniaud32. linux seems to use dmix as a software mixer - so in my mind I'm thinking uniaud16 writes multiple streams to dmix, which writes a consolidated single stream to uniaud32.

I have no idea how difficult this would be to implement, I've never written a device driver - I port code, I don't write it :)

For largely academic interest purposes, I'd like to support the multiple streams on hardware that supports it natively - there should be some clues in the sblive driver on how this was don't on OS/2, which I'm hoping can be adapted into uniaud. I'm not sure yet if this will require uniaud16 and/or uniaud32 changes.

I'll explore as time permits.

Cheers,

Paul

Paul Smedley

  • Hero Member
  • *****
  • Thank You
  • -Given: 57
  • -Receive: 110
  • Posts: 809
  • Karma: +50/-0
    • View Profile
Re: Updated Uniaud32 build
« Reply #516 on: January 20, 2021, 09:44:32 am »
For largely academic interest purposes, I'd like to support the multiple streams on hardware that supports it natively - there should be some clues in the sblive driver on how this was don't on OS/2, which I'm hoping can be adapted into uniaud. I'm not sure yet if this will require uniaud16 and/or uniaud32 changes.

As a minimum - changes to uniaud16 would be required for devices that support hardware mixing (ie sblive). This will need some quality time studying the sblive16 code and seeing how that code can be integrated into uniaud16 - and of course, other than making sure it doesn't fail on hardware that only supports a single stream, I can't test it locally.

For a software mixing solution, I have no real idea on how this could be done...

Andi B.

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 25
  • Posts: 559
  • Karma: +3/-1
    • View Profile
Re: Updated Uniaud32 build
« Reply #517 on: January 20, 2021, 10:58:21 am »
Quote
For a software mixing solution, I have no real idea on how this could be done...
I have. From very simple (>> 1 to make half level and add every sample from both streams. Given they have the same sample rate) to sophisticated complex with filtering and ... :-). You will run into problems like clicking noise very fast. The same as you will when doing it in the analog world. I think you quickly will desire some fading and 'switching at (near) zero level'. And then volume control before mixing and mixing of different sample rates and ....

This all gets rather complex quickly. Given our OS will never be again a compatible sound processing platform and PC hardware in general isn't usable for any serious sound processing stuff, at least not the hardware we have drivers for, IMHO it's not worth to spend much time on this.

Probably I've lost track in this thread. But can someone tell me why we want to have 'mixing of channels'? And which channels do we want to mix?

Ian Manners

  • Global Moderator
  • Sr. Member
  • *****
  • Thank You
  • -Given: 49
  • -Receive: 32
  • Posts: 400
  • Karma: +5/-0
  • I am the computer, it is me.
    • View Profile
    • ComKal Networks Australia
Re: Updated Uniaud32 build
« Reply #518 on: January 20, 2021, 11:28:32 am »
can someone tell me why we want to have 'mixing of channels'?

I'm wondering as well. I use two analog mixing consoles as I find real knobs easier to use and set, and if recent cards no longer have streams it means there is a limited audience for it.

In saying that :)

Paul, I'm happy to post you a SBLive PCI card at no cost to you. Not sure if that would help if your using a VPC.
alsa-sblive.log
 GetUniaudPcmCaps: cp1. pcm 0, phandle f5e0e4bc
  GetUniaudPcmCaps: pcm 0, cp2. nr of streams: 32
  chan: from 1 to 2
 GetUniaudPcmCaps: cp1. pcm 0, phandle f5e0eee8
  GetUniaudPcmCaps: pcm 0, cp2. nr of streams: 1
  chan: from 1 to 2
Cheers
Ian B Manners

Paul Smedley

  • Hero Member
  • *****
  • Thank You
  • -Given: 57
  • -Receive: 110
  • Posts: 809
  • Karma: +50/-0
    • View Profile
Re: Updated Uniaud32 build
« Reply #519 on: January 20, 2021, 09:30:15 pm »
Hi Andi,

Quote
For a software mixing solution, I have no real idea on how this could be done...
I have. From very simple (>> 1 to make half level and add every sample from both streams. Given they have the same sample rate) to sophisticated complex with filtering and ... :-). You will run into problems like clicking noise very fast. The same as you will when doing it in the analog world. I think you quickly will desire some fading and 'switching at (near) zero level'. And then volume control before mixing and mixing of different sample rates and ....

This all gets rather complex quickly. Given our OS will never be again a compatible sound processing platform and PC hardware in general isn't usable for any serious sound processing stuff, at least not the hardware we have drivers for, IMHO it's not worth to spend much time on this.

Probably I've lost track in this thread. But can someone tell me why we want to have 'mixing of channels'? And which channels do we want to mix?

Sorry - I know there's libraries to merge different streams - dmix for example is used on some linux systems - when I say  'no real idea on how this could be done' I more mean the mechanics of *how* this could be done between uniaud16 and uniaud32.

In terms of the 'why' we might want this - one simple example is to mix in system notifications with a mp3 stream, rather than the annoying pause the mp3, play the system sound, resume the mp3 behaviour.

Paul Smedley

  • Hero Member
  • *****
  • Thank You
  • -Given: 57
  • -Receive: 110
  • Posts: 809
  • Karma: +50/-0
    • View Profile
Re: Updated Uniaud32 build
« Reply #520 on: January 20, 2021, 09:32:53 pm »
Hi Ian,

can someone tell me why we want to have 'mixing of channels'?

I'm wondering as well. I use two analog mixing consoles as I find real knobs easier to use and set, and if recent cards no longer have streams it means there is a limited audience for it.

In saying that :)

Paul, I'm happy to post you a SBLive PCI card at no cost to you. Not sure if that would help if your using a VPC.

Thanks Ian - at this stage I have no hardware that has a PCI slot - all my physical hardware in the house is either a Thinkpad, or a variant of a Raspberry Pi.

Hold that thought for now - I've half thought to set up some physical hardware running ArcaOS - I just need to work out where I'd set this up with access to a display.

Cheers,

Paul

Andi B.

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 25
  • Posts: 559
  • Karma: +3/-1
    • View Profile
Re: Updated Uniaud32 build
« Reply #521 on: January 21, 2021, 09:03:51 am »
Quote
...system notifications with a mp3 stream, rather than the annoying pause the mp3, play the system sound, resume the mp3 behaviour...
Thanks for the reminder. Understood now. I don't mind about such things probably cause I never ever let a system produce useless noise in my environment. But of course this is a personal habit.

David McKenna

  • Sr. Member
  • ****
  • Thank You
  • -Given: 12
  • -Receive: 25
  • Posts: 331
  • Karma: +13/-0
    • View Profile
Re: Updated Uniaud32 build
« Reply #522 on: January 21, 2021, 11:42:53 pm »
In terms of the 'why' we might want this - one simple example is to mix in system notifications with a mp3 stream, rather than the annoying pause the mp3, play the system sound, resume the mp3 behaviour.

 Exactly! This has been my pet peeve for OS/2 since the CompuServe days. Even Win 3.1 could handle this. SBLive cards handled it on OS/2 with Sander's driver, but PCI slots were last seen riding into the sunset. Guess audio chips nowadays tend not to support it directly, but rely on the OS to do mixing. Unless there are PCIe cards that support hardware multiple streams?....

Regards,
« Last Edit: January 21, 2021, 11:56:18 pm by David McKenna »

Lars

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 71
  • Posts: 749
  • Karma: +14/-0
    • View Profile
Re: Updated Uniaud32 build
« Reply #523 on: January 22, 2021, 12:14:14 am »
But you can only easily mix PCM streams. If you have something else like MPEG you need to decode first. And if you want to do this in real time, you need a block oriented codec with a fixed and fairly small block size. I would think that mixing capable HW will mix the analog output signal. But that would require multiple analog internal outputs.

Paul Smedley

  • Hero Member
  • *****
  • Thank You
  • -Given: 57
  • -Receive: 110
  • Posts: 809
  • Karma: +50/-0
    • View Profile
Re: Updated Uniaud32 build
« Reply #524 on: January 22, 2021, 10:52:09 am »
Very much thinking out loud.....

Looking at https://www.github.com/komh/kai/tree/master/libkai.txt it seems that KO's libkai 2.0 has a soft mixer.

I wonder if uniaud16.sys could be adapted to call libkai.dll rather than uniaud32 sys? I have no idea if it's even possible for a 16 but mmpm driver to call a 32 bit DLL, as I say, just thinking out loud for now....