search

PortAudio / portaudio

PortAudio is a cross-platform, open-source C language library for real-time audio input and output.
Other
1.39k stars 292 forks source link

add callback API for detecting connection/removal of devices (aka "hotplug") #11

Open PortAudio-admin opened 17 years ago

PortAudio-admin commented 17 years ago

Issue created by @RossBencina

Add an API to allow clients to be notified (or to poll) for whether audio devices have been connected or disconnected.

PortAudio-admin commented 17 years ago

Comment by @RossBencina

Robert Bielik adds: As it is now, the available audio devices are discovered during Pa_Initialize(). I'd like to have it possible to check if any new devices have been added (such as a headset), while still playing a stream with connected devices. Would that be possible?

PortAudio-admin commented 16 years ago

Comment by @RossBencina

Erik Bunce submitted a patch for this in October 2007: http://techweb.rfa.org/pipermail/portaudio/2007-October/007719.html

There were a number of issues raised, see discussion in October: http://techweb.rfa.org/pipermail/portaudio/2007-October/thread.html#7719 and November: http://techweb.rfa.org/pipermail/portaudio/2007-November/

All under the subject "Plug-and-play patch for portaudio"

From memory one of the issues was concerned with dealing with concurrency issues.

This issue needs to revisited and a decision reached.

PortAudio-admin commented 13 years ago

Comment by @RossBencina

r1663: merged initial two-stage-commit hot-plug patch from David Stuart into branches/hotplug, with ds implementation only, including:

Open questions:

r1664 includes a cleaned up version of pa_win_ds.c where the scanning code is also used by Initialize()

PortAudio-admin commented 13 years ago

Comment by @RossBencina

For the open issues about the notification mechanism mentioned in comment 2 above see: http://music.columbia.edu/pipermail/portaudio/2007-October/007723.html http://music.columbia.edu/pipermail/portaudio/2007-October/007724.html http://music.columbia.edu/pipermail/portaudio/2007-November/007747.html http://music.columbia.edu/pipermail/portaudio/2007-November/007749.html http://music.columbia.edu/pipermail/portaudio/2007-November/007757.html

PortAudio-admin commented 12 years ago

Comment by @RossBencina

TRAC migration: propagating ticket status from TRAC

PortAudio-admin commented 12 years ago

Comment by @RossBencina

portaudio-deviceschanged.patch.txt

portaudio-deviceschanged.patch (44.7 KB) - added by rossb 4 years ago. Eric Bunce's Plug-and-play patch for portaudio, see http://techweb.rfa.org/pipermail/portaudio/2007-October/007719.html

[Portaudio] Plug-and-play patch for portaudio Erik Bunce Mon Oct 29 23:02:01 EDT 2007 """ Please see the attached patch against todays portaudio v19-devel r1296. It defines API's to support plug-and-play and adds an implementation to the hostapi for Mac OS X.

Highlights includes the following:

Thank you for your consideration.

Thanks and Enjoy, Erik Bunce """

PortAudio-admin commented 7 years ago

Comment by @RossBencina

Patches from Ingo Bauersachs of jitsi:

This is the source we're currently using: https://github.com/jitsi/libsrc/blob/master/portaudio.zip

The should be the diff from SVN-1677 to what is in the above .zip: https://github.com/ibauersachs/portaudio/commit/df0179c28863ae122e5d37f4a9b4 2b7a8dd806fc

And the wmme-patch is on our list archives: http://lists.jitsi.org/pipermail/dev/2012-July/004183.html

There are useful commit messages with details about the patches here: https://github.com/jitsi/libsrc/commits/master/portaudio.zip

This is now in PortAudio GIT as a sequence of commits here: https://app.assembla.com/spaces/portaudio/git/merge_requests/3784323?section=commits

PortAudio-admin commented 7 years ago

Comment by @RossBencina

Here is my review of the jitsi patch from here: https://github.com/jitsi/libsrc/blob/master/portaudio.zip (relative to r1677) Diff here: https://github.com/ibauersachs/portaudio/commit/df0179c28863ae122e5d37f4a9b4 2b7a8dd806fc

Also available in PortAudio GIT: https://app.assembla.com/spaces/portaudio/git/merge_requests/3784323?section=commits

(Note: the MME mailing list patch seems redundant. It is slightly different from 5ca6fed, but doesn't appear to contain any functional differences. http://lists.jitsi.org/pipermail/dev/2012-July/004183.html)

The changes seem to fall into the following categories:

  1. Refactor device enumeration to support the hotplug refresh interface. Mostly moving code around. The patch includes this code for pa_linux_alsa, pa_mac_core, and pa_win_wmme.
  2. Rework timeouts and/or add additional timeouts to deal with devices timing out when disconnected while a stream is running (quite a lot of this code for ALSA, CoreAudio and WMME).
  3. Device inserted notification engines for Mac and Linux. The Linux one is very rudimentary and uses a sleep()/polling loop. The Mac one is simple, but uses core audio notifications as you'd expect.
  4. Addition of deviceUID and transportType to PaDeviceInfo. We won't accept this but maybe some of it will be used internally, especially deviceUID
  5. A few behavioral tweaks (e.g. disable wavemapper on Windows). Some of these we won't accept.

Broken down by file. I've marked changes that we won't accept with WONTFIX

Routine Changes

Makefile.in

configure configure.in

Major Changes Incl. Hotplug

src/hostapi/alsa/pa_linux_alsa.c

src/hostapi/coreaudio/pa_mac_core.c

src/hostapi/coreaudio/pa_mac_core_blocking.c

src/hostapi/coreaudio/pa_mac_core_blocking.h

src/os/win/pa_win_hotplug.c

src/hostapi/wmme/pa_win_wmme.c

New Files Incl. Hotplug

src/os/mac_osx/pa_osx_hotplug.c

src/os/unix/pa_linux_hotplug.c

Non-Hotplug Tweaks We Might Want (or not)

include/pa_mac_core.h

src/hostapi/wdmks/pa_win_wdmks.c

Changes Already In PA/hotplug

src/hostapi/asio/pa_asio.cpp src/hostapi/jack/pa_jack.c src/hostapi/oss/pa_unix_oss.c src/hostapi/skeleton/pa_hostapi_skeleton.c src/hostapi/wasapi/pa_win_wasapi.c

WONTFIX

include/portaudio.h

src/common/pa_front.c

src/hostapi/dsound/pa_win_ds.c

test/patest_update_available_device_list.c

PortAudio-admin commented 7 years ago

Comment by @RossBencina

Here's a breakdown of the separated Jitsi commits that are available in PortAudio GIT here: https://app.assembla.com/spaces/portaudio/git/merge_requests/3784323?section=commits

b77a1f828c5cd683b7f10e419b815f31bbefeba6

e7a274942b7edbd18a91c37be34355adbe6e0013

0a7b80cfce90bf5973952c1c4ab760efc3559830

15d77417bf2862a079abd7ec703c2aedcde2b120

6c6269425f647a82986b152584849b5fd827510d

c534056a7b344ad42811463c9d6a6b378a64fff1

ab8b64023c7900b2e067998087adf89a96ad7cff

66bda13f84944b8d282c52141117e2234dca8ed6

raveslave commented 1 year ago

checking in whats the status for connectionId and identifying sound cards (if many) by the raw usb-descriptor serial number

RossBencina commented 1 year ago

@raveslave status is that connectionId iss part of hotplug spec, there is partial implementation in the stale branch. I don't think most USB devices have serial numbers.

raveslave commented 1 year ago

any plans on merging? I've tried a bunch of various sound cards and they all have serial-nos in the main descriptor.

RossBencina commented 1 year ago

@raveslave: out of interest, can you give examples of the devices with unique serial numbers?

raveslave commented 1 year ago

@RossBencina

Here is the top level descriptor for a Motu M2:

 Product ID:    0x000b
 Vendor ID: 0x07fd
 Version:   2.03
 Serial Number: M2AE0F58N7
 Speed: Up to 480 Mb/s
 Manufacturer:  MOTU
 Location ID:   0x14800000 / 25
 Current Available (mA):    500
 Current Required (mA): 500
 Extra Operating Current (mA):  0

would be great if portaudio exposes pid, vid, version, serial, mfg as well as usb port this way we can better identify whats connected, especially when dealing with multiple sound-cards ...and in my case, I need to calibrate each sound-card so this would be stored linked to the serial-no

related when used with sounddevice,
serial would be essential here

sounddevice.query_devices(2)
{'name': 'M2', 'index': 2, 'hostapi': 0, 'max_input_channels': 2, 'max_output_channels': 2, 
 'default_low_input_latency': 0.01, 'default_low_output_latency': 0.0045578231292517, 
 'default_high_input_latency': 0.1, 'default_high_output_latency': 0.014716553287981859, 
 'default_samplerate': 44100.0}_
JoergAtGithub commented 1 year ago

The USB Serial Number is not a good identifier for this purpose:

  1. It only work for USB sound devices, but not for Bluetooth, Firewire, etc.
  2. Many cheap devices have no programmable memory. Therefore the manufacturers use the same Serial Number for all devices of a type - this is a violation of the USB specification, but unfortunately common in the field.

Instead you should use the unique device identifiers, which the operating systems assigned at runtime. These are:

  1. On Windows you have DEVPKEY_Device_ContainerIdwhich suits perfect here
  2. On MacOS you've LocationIDs like kUSBDevicePropertyLocationID(every MacOS subsystem API calls them slightly different)
  3. On Linux you have to use libudev, determine the parent device using udev_device_get_syspath(might need multiple iterations) and than get it's syspath string using udev_device_get_syspath
raveslave commented 1 year ago

I still think the usb descriptor serial should be exposed as this is the only identifier (available on most pro-sumer / professional sound cards) to allow calibration, i.e. measured setups, needing to know which exact soundcard is connected.

The location-id is good to but changes upon each reconnect or reboot. How about offer both and let the application choose how to use them?

JoergAtGithub commented 1 year ago

The location-id will always work, it's a guranteed unique identifier. Using this unique identifier as reference, you can gather any additional information, like the USB serial number. The other way around, it wouldn't work reliable, because there could be more than one device using the same USB serial number.

raveslave commented 1 year ago

how about offering both, with location-id being the primary?

its important you can move a soundcard from one machine to another and still knowing which one it is afaik, location-id will not be same in that use-case

Chum4k3r commented 1 year ago

Well, you can build a hash from a few known values that are guaranteed to be the same, no matter where you plug, and use this hash to map to your calibration signal.

This method also delivers the freedom to not depend on PA providing such identifier.

And still, you can use these IDs you are looking for to build such hash.

I've built a python library that uses PA as "audio engine" for room acoustics measurements (PyTTa), and our lab's technique to keep the calibration between measurements and even between measurement sessions, for any reason, was exactly a hash map like this.

Em seg, 9 de jan de 2023 17:46, david eriksson @.***> escreveu:

how about offering both, with location-id being the primary?

its important you can move a soundcard from one machine to another and still knowing which one it is afaik, location-id will not be same in that use-case

— Reply to this email directly, view it on GitHub https://github.com/PortAudio/portaudio/issues/11#issuecomment-1376293749, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJPYUKCPFIPUHAHNSNF34WLWRR2MHANCNFSM6AAAAAASYGPLUI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

MrKepzie commented 12 months ago

What's the status on the hotplug branch ? It looks like it is stale for almost 7 years now; How far is it to be usable ?