earlephilhower / arduino-pico

Raspberry Pi Pico Arduino core, for all RP2040 and RP2350 boards
GNU Lesser General Public License v2.1
2.01k stars 419 forks source link

Support for UAC2 devices thru TinyUSB #942

Closed lu7did closed 1 year ago

lu7did commented 1 year ago

Hi, I'm trying to implement a UAC2 device with this core using TinyUSB, but the porting from the example prrogram (uac2_headset.c) had prooven extremely complex because of the dependencies. In turn the Adafruit TinyUSB support lacks UAC2 examples or support. Is there any help/hint/support/example you can provide to achieve that? Thanks in advance for your kind attention, Pedro

earlephilhower commented 1 year ago

Until your note the only UAC I knew about was this!

My best suggestion would be to ask in the Adafruit TinyUSB repo, or the RPi forum proper. There is a USB audio adapter sample in the pico-examples repo as well, but I don't remember seeing anything about UAC in that.

TobiasVanDyk commented 1 year ago

Yes one has to also look at the additional set of Pi Pico examples: https://github.com/raspberrypi/pico-playground/blob/eb6658e82069c603244b42d2bdd858a3fa270c63/apps/usb_sound_card/usb_sound_card.c#L325 / Current volume. See UAC Spec 1.0 p.77 /

lu7did commented 1 year ago

Checking with TinyUSB developers they doesn't seems to have an implementation of UAC2 anytime soon on their roadmap, therefore this seems to be a dead end. Examples on the pico-playground (as suggested before) doesn't compile under the core nor seems to be easily adaptable because of the dependencies not being fulfilled. This core is superior to other equivalents but still has no support for audio over USB (i.e. the mbed core provides the USBAudio objetc with that purpose).

Is there any plan to move into that direction the Arduino core? Thanks in advance, Pedro.

earlephilhower commented 1 year ago

Sorry, but it's not something on my own roadmap. I'm always happy to get PRs implementing neat things like this, of course. But given my limited time to work on this, I try to prioritize more generally applicable updates.

If the pico-playground app does what you need, why not use the raw SDK and that code directly? Installing the SDK now is a 1-click process, thanks to work the RPi guys have done since release.

lu7did commented 1 year ago

I think this core is superior to other alternatives.

I don’t need much help to install VS as it is an environment I use for works since long ago.

But in doing so I could not leverage on the huge support of the Arduino libraries available when developing with your core.

I hope at some point you revisit to consider this feature in your roadmap.

Regards, Pedro

On Sun, 7 May 2023 at 19:56 Earle F. Philhower, III < @.***> wrote:

Sorry, but it's not something on my own roadmap. I'm always happy to get PRs implementing neat things like this, of course. But given my limited time to work on this, I try to prioritize more generally applicable updates.

If the pico-playground app does what you need, why not use the raw SDK and that code directly? Installing the SDK now is a 1-click process, thanks to work the RPi guys have done since release.

— Reply to this email directly, view it on GitHub https://github.com/earlephilhower/arduino-pico/issues/942#issuecomment-1537559263, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHQ4QILMPQM2PRFSXIDJH4DXFASBHANCNFSM6AAAAAARRKAY74 . You are receiving this because you authored the thread.Message ID: @.***>

DragRedSim commented 11 months ago

Yes one has to also look at the additional set of Pi Pico examples: https://github.com/raspberrypi/pico-playground/blob/eb6658e82069c603244b42d2bdd858a3fa270c63/apps/usb_sound_card/usb_sound_card.c#L325 / Current volume. See UAC Spec 1.0 p.77 /

Just posting for reference here; the linked example does not use any TinyUSB code. As the information in that repo’s read me states, it was developed on preproduction hardware before the officially supported software stack was finalised, and as such uses LUFA to achieve its sound card output. This would make it more difficult to directly port forward, as the stack would also need to be updated respectively; as such, I would suspect it would not be something to use as a baseline to develop off of in its current state.