Search results

I checked the boards.local.txt file in the PR and saw that it had already been fixed there. Otherwise, I would have let you know.

Just as all the other audio headers usb_audio.h would be included in Audio.h. Here it can be included only for the T4.0/T4.1 by means of preprocessor conditional. So it would not affect the other Teensys. I suggested it because there is just no reason for usb_audio.h to be part of the core...

Regarding merging the new usb interface into the core and audio library: At the new interface, I separated the more complex USB audio functionality from the audio library: - USBAudioInInterface and USBAudioOutInterface of usb_audio_interface.h/cpp contain the more complex implementation...

@h4yn0nnym0u5e Thanks for submitting the pull request. Right, I added mute and volume controls. It is implemented in a similar way to the current usb audio interface. That means the volume and and mute signals are received by the usb interface, but not directly applied. Instead the current...

Right, it looks like the problem is solved.

Nice to hear that your problems with the USB interface have been solved. Thanks also to h4yn0nnym0u5e for helping me and contributing to the USB audio interface. If you are not quite sure whether buffer over- or underruns occur even after startup, you could also use the getStatus function of...

I finally found the time to work on the LastCall class. This class is used to measure the time of update- and isr- calls. The goal was to increase the performance of the class but also keep the outlier detection. (An outlier in this context is e.g. a delayed update call due to a higher priority...

Thanks for fixing that. I took the abbreviations for the channel names directly from the USB specification and didn’t notice the warnings. Interestingly, the bottom center and back center channels are both called BC in the specification. Thanks also for testing the new getTransmissionTarget()...

Ok, I’ve rewritten the function getTransmissionTarget(). I think it’s simpler now and shouldn’t run into integer overflow.

Thanks for fixing that. Back then I only tested the common sampling frequencies. For now I merged your pull-request, but I hope that I'll soon find the time to refactor the function and to improve it. Shouldn't be too difficult. Unfortunately, I am still busy with two other projects.

Hi, thanks for having a look at the problem. The assumption that the interval between two update calls is always longer than the interval between the usb transmit/ receive interrupts is of course not true for small block sizes. Thank you for identifying the main problem. Regarding clearing the...

I forgot, you already pointed out a suspicious section of the code. I’ll look into it over the weekend, and I’m sure I’ll also find some time to fix the spelling error. 😅

The concept is the same as with the original usb implementation: We have a target buffer level. The error is the deviation of the actual buffer level from the target. We use the error as the input for a PI controller and the feedback is the default feedback plus the output of the controller. The...

Hi, I am a bit late to the discussion. Here are my two cents to the topic: As already mentioned it is completely normal that the clocks of the host and the Teensy don't match perfectly. I don't think that the clocks between audio host and audio interface ever match. There are different solutions...

Unfortunately, I am currently really busy with other stuff. I guess, I can start having a look at the usb audio issues next week end (not the upcoming one). I think I will first try to solve the problems related to small block sizes, then we need to improve the perfomance of 'LastCall'. After...

I didn't have a look at the code, but is the function we see in the saw tooth plot a downsampled/ aliased version of the original saw tooth? That would explain your observation. That might be. Since it depends on the host and we can't test it for all hosts, I would still try to get an...

Thanks for testing. I think I should first fix it for Windows 11. I assume it will then also work for other operating systems. I'll have a look at that.

Ok, interesting. As you noticed, I didn't assume that a block will always have 128 samples at the implementation. But I also didn't put too much thought in keeping it working for small block sizes. (and I never tested smaller block sizes) That might be the problem. I'll have a look at it. I...

@tomas Not really. I use the Teensy in my hi-fi system, and low latency isn’t important for my application. Also, I’m already struggling to get the interface working with the standard driver. I really don’t need any additional challenges right now. 😅

Thanks for the files. I’ll take a look at them as soon as I have some spare time. I think I should have explained how the LastCall algorithm works before you started your evaluation. Unfortunately, I’m currently very busy and didn’t manage to find the time during the week. Regarding the...

Hi, thanks for investigating the code. Some remarks from my side: Just filtering the time doesn't make sense of course. At my first attempts I also filtered durations. Back then I used a second order filter instead of a exponential smoothing. But in the end the question is: How to get an...

Hi, thank for your feedback. I can try to make the History more efficient. I implemented it to estimate the number of buffered samples at my spdif resampling. Here it was crucial to get a very accurate estimation of the last calls of the 'update' as well as the 'isr' functions. Maybe that...

That's great to hear! Thanks for helping us grow the set of successfully tested USB hosts. Wishing you lots of success with your projects.

So it's a known quirk of the macOs driver. Funny thing: When Weiweiweiwear and I tried to solve the issue, I also made a version of the audio interface at which I mixed the code from the current Teensy audio main branch with my current implementation: All UAC1 related stuff (e.g. descriptors...

I think the problem is caused by the following code: // Called from the USB interrupt when ready to transmit another // isochronous packet. If we place data into the transmit buffer, // the return is the number of bytes. Otherwise, return 0 means // no data to transmit unsigned int...

I think, I found the problem. I'll try to fix and test it on Saturday.

Wow! This are great news! Thank you for your help. I'll have a look at the code and try to spot the missing initialization that causes the problem.

This is interesting. With the script main_usbOutput.ino, did you also try playing some audio on the Mac? With that script incoming audio is just discarded. If the "overload" issue doesn't appear in the log and everything looks fine on the Mac, then we might have a clue as to which part of the...

Thank you very much for your test and the log output! I'll have a closer look at the log output next weekend. If you have some time, could you maybe also test the usb output example 'main_usbOutput.ino' and again have a look at the log output? I am just curious if the problem is only related to...

Hi, it looks like the same issue that's occurring on Weiweiweiwear's Mac. A plausible explanation is that it's related to the feedback the Teensy sends to the USB host: This would explain why the problem doesn't occur on all Macs—it depends on the clock difference between the USB host and the...

Good point. I added a MIT license. Did you already test the usb interface with more than two channels?

I am glad that you managed to get it working. Let's hope that 8 channels also work.

Hi, some people succefully tested the multichannel usb audio class with Mac. On the other hand we know at least of one case at which it didn't work. So I guess you just need to try it. You would need Teensyduino 1.59. Then you can follow these instructions for the installation of the the...

Unfortunatelly, I can't help you with the CS42448 and I don't know how it behaves if you switch from AudioOutputTDM to AudioOutputI2S. Have you used the CS42448 succefully with the Teensy? Maybe with the current stereo usb interface? If yes, then I recommend to use the sketch that is working and...

Exactly!

When I need to debug a sketch, I like to implement a minimum example that allows me to reproduce the problem. In case of the usb interface, I would use the two very simple examples main_usbInput.ino and main_usbOutput.ino. They rule out that there is a problem with the codec. Also, they provide...

Thanks for testing. On the one hand, I’m glad that the USB interface works for all your Macs. On the other hand, it's still a mystery why it’s not working for Weiweiweiwear. I guess we have to wait until somebody can reproduce the problem on another Mac.

@electricat Thanks for the tests. @h4yn0nnym0u5e implemented the example sketch with the sgtl5000. Generally, there shouldn’t be any issues if no USB host is connected to the Teensy and I assume this behaviour is specific to the sketch. I’ve just committed an update to my usb output example...

@electricat Thanks for testing and for the good news! @h4yn0nnym0u5e I can't think of any additional information that would be helpful. We tested stereo and 8-channel audio on @Weiweiweiwear's Mac, using both 16-bit and 24-bit configurations. It didn’t seem to make a difference, but it's still...

Thanks a lot for your help, @wll3mx! If you have an SGTL5000, you can run the tests suggested by @h4yn0nnym0u5e . However, if you don’t have an SGTL5000, you can use main_usbInput.cpp instead, as it doesn’t require any additional hardware. To test using this example, follow these steps: Make...

I'm not sure if the issue you found is related. One reason that suggests it might not be is that I implemented a mixed version of both the new and old USB audio interfaces. It uses the UAC1 standard from the current T4 implementation, but most of the other code is based on my own implementation...

Hello everyone, It's been a while, and I just wanted to give a quick update on the status of the multi-channel USB audio interface. The good news: I tested the interface today on my Samsung smartphone (Android 14), and it worked right away. Unfortunately, we haven't been able to solve...

I really appreciate your efforts to help. In our last tests, we removed the audio codec from the Teensy because it wasn't necessary to reproduce the issue. The problem that Weiweiweiwear is facing seems to be related to the USB input, particularly to my implementation of the UAC2 standard.

Thanks for pointing that out. I think I confused AntiLoop with Toyosm.

I can give more details about what we tried: At our tests we set the number of channels to 2, we chose 44.1kHz as sample rate and 16bit resolution. We used the simple usb input example from my repository. There were no buffer over- or underruns and we received a signal at the Teensy. The...

@Weiweiweiwear I thought the Teensy is powered by the usb connection to the Mac? If you are talking about the power supply of the audio codec: I think it's best to disconnect the audio codec from the Teensy. For debugging it's normally best to find a hardware setup and software that is on the...

For those who are curious about Weiweiweiwear's problem: We had a long video call this afternoon/evening and tried to find out what the problem is. Unfortunately we were not successful yet. In the end we compared the original usb input with my version (both in stereo). The original code worked...

When I asked you to make a test in stereo, I meant you should select only two number of channels in the Tools menu as described in the 'In use' section of the README.md and connect only channel 0 and 1 with audio connections in the example code (as you already did in the example above). If you...

@AntiLoop: You are right, the cs42448 needs to be initialized. However, this can easily be fixed for sure and I am much more concerned about the problem with the usb input at the moment. I asked @Weiweiweiwear to do use the simple example just to remove the tdm ouput and the cs42448 as sources...

@Weiweiweiwear: Thank you for the test. At least we know you problem has nothing to do with your audio codec or its configuration. Once I had a similar problem and the reason in my case was a broken usb cable. I connected the Teensy and started playing music. It worked for some time (a few...