Audio via headset


I looked it up, the Pyra has the TL1837MOD.. I can't find much info about the WL1857 module mentioned in above diagram..
The TL1837 indeed seems to not have the FM part in it.. That's too bad... :)
I think obsolete stuff like this should be broken out of the audio driver imo,also the amount of audio devices to choose from is just a bit too much. To me it's unclear what is/does what...
In the picture a small part of the whole list...
 

Attachments

  • 16365367672433101472976630667864.jpg
    16365367672433101472976630667864.jpg
    1.1 MB · Views: 194
You can still easily buy an FM radio here, so I doubt they're turning it off soon. I'd have though the spectrum would be pretty rubbish for mobile data, as the bandwidth at up to a couple hundred megahertz while very high when FM radio came about, is nothing compared to the hundreds of megahertz that 2G ran on, and 3G mostly ran on about a thousand megahertz, 4G and on is on a handful of gigahertz.

Theoretically there's harmonics from these hundred or so Megahertz going up in octaves (half the wavelength, double the frequency) but attenuating significantly as they go up, which is perhaps why 2G started at about 450MHz, and 3G at about 850MHz.
Post automatically merged:

I looked it up, the Pyra has the TL1837MOD.. I can't find much info about the WL1857 module mentioned in above diagram..
The TL1837 indeed seems to not have the FM part in it.. That's too bad... :)
I think obsolete stuff like this should be broken out of the audio driver imo,also the amount of audio devices to choose from is just a bit too much. To me it's unclear what is/does what...
In the picture a small part of the whole list...
Presumably the telephony parts are modem voice coils, and the HDMI parts are for HDMI audio out. I'm not sure what the card parts are.
 
  • Like
Reactions: rSl
It was just a Missinformation i get myself some months ago, so i dit search for a Solution against Silence in my FM Radio Car (alltough i have also CDs ), its not that easy to put there a DAB+ Radio in as its got a Factory Stock Radio, allthough whit Mp3 CD but whitout Shuffle Mode..

Now i can listen to the Music from my Iphone, or Rock Streams, the only issue is that the Frequency you chose for the Transmitter some times is the same as a Radio Station you get when you are on a different part of Germany.. ^^
My Dads Car is there a bit better: Still FM, but whit a Bluetooth Build In..

My Wishlist for my next Car gets quite Big..
 
Had look at the schematics. What I learned: Way out of my skillset.
I don't even understand the amount of connectors for "just interchange 2 pins".
So I guess I just have to wait, till that is fixed by someone or I'll give up on the idea to have the pyra as my main computer. Let's see what comes first.
 
Honestly would rather miss this one odd feature for a more simplified Pandora like Sound system that didn't eat CPU cycles dealing with volume control.
That's what we planned - and why the alternative chip even was implemented on earlier revisions.
However, the OMAP5 does not support any kind of a simple DAC like the OMAP3 does. The only way to use sound is the PALMAS... and that's where the driver has issues.

About the noise on the headset port: I can imagine something is actually interfering into the audio there.
As the PALMAS is near the SoC (it has to be, that's TIs setup), analog audio goes from near the SoC to the speakers and headset port as well.
Shielding it fully from interference would probably cost a few 10k EUR for going into a lab, doing measurements, changing the setup, etc.

That does not mean it can't be software though. We know the random audio crashes through the speakers can be totally disabled when the mic stream is disabled. It's not enough to mute the mic - disabling the stream is what's important.
Maybe something like this works here as well.

There are two important things to consider: There's software volume and hardware volume.
If the hardware volume is set to very low, it will pick up more noise as to when it's set to a high value.
So the hardware volume should be set to a high value and the software volume to a lower one.

I don't really know myself how this hardware / software should be setup properly, but I can imagine using the hardware codec will improve things a lot, as the hardware supports various effects (and probably also something like noise filtering)
 
The audio hardware isn't the cause of the volume wheel eating lots of cpu cycles though, that's to do with the AD converter taking forever to return the state of the volume wheel.
 
The audio hardware isn't the cause of the volume wheel eating lots of cpu cycles though, that's to do with the AD converter taking forever to return the state of the volume wheel.
Does that ADC have a section in the DTS?, wonder if the precision set too high, just something I recall dealing with some I2C and SPI ADCs I bought for a RPi project.
 
  • Like
Reactions: rSl
As the PALMAS is near the SoC (it has to be, that's TIs setup), analog audio goes from near the SoC to the speakers and headset port as well.
Shielding it fully from interference would probably cost a few 10k EUR for going into a lab, doing measurements, changing the setup, etc.
Sorry that I don't know what I'm speaking about and I may make no sense at all. But could one future hardware revision remove the analog audio track and have only a connector near the PALMAS where properly shielded cables to the speakers connect ?
I know that would complicate assembly, and maybe there's either no physical room, or too much electromagnetical noise to shield thin enough cables that still fit.
 
Does that ADC have a section in the DTS?, wonder if the precision set too high, just something I recall dealing with some I2C and SPI ADCs I bought for a RPi project.

It's connected to "voltage2" of palmas-gpadc , which has a very short section in the dts.
kernel driver itself is at drivers/iio/adc/palmas_gpadc.c , which points to a few other places.
I'm not sure what the other channels are used for, but if they're getting read from other places, it might be causing the volume iio readings to slow down.
 
  • Like
Reactions: rSl
The audio hardware isn't the cause of the volume wheel eating lots of cpu cycles though, that's to do with the AD converter taking forever to return the state of the volume wheel.

Yes, I was expecting that it'll work on a push basis, so that it will only send signals when the value has changed :(
I didn't expect a full polling here.

However, that still can be fixed if functions are implemented like here: https://pyra-handheld.com/boards/threads/improve-volume-wheel-daemon-bounty.99430/
Change the pull frequency when the value changes a lot, disable polling when no audio stream is enabled, etc.

You didn't like elw3 solution which seems to work but is not easy to integrate...? I didn't understand your problem that well, but I'm no dev.

But it seems to be at least a working proof of concept, so if someone could create a proper daemon from that, it should improve a lot.
 
About the noise on the headset port: [..]
There are two important things to consider: There's software volume and hardware volume.
If the hardware volume is set to very low, it will pick up more noise as to when it's set to a high value.
So the hardware volume should be set to a high value and the software volume to a lower one.

I don't really know myself how this hardware / software should be setup properly, but I can imagine using the hardware codec will improve things a lot, as the hardware supports various effects (and probably also something like noise filtering)
Sadly pulsaudio does another naming
Are those the "Hardware/Virtual devices in the pulsaudio setting?
That does not mean it can't be software though. We know the random audio crashes through the speakers can be totally disabled when the mic stream is disabled. It's not enough to mute the mic - disabling the stream is what's important.
Maybe something like this works here as well.
Can that be done via Alsa/pulseaudio settings or is that something to be done in the config files? I'm fine with both, just need to know which and where
 
Sadly pulsaudio does another naming
Are those the "Hardware/Virtual devices in the pulsaudio setting?

Pulseaudio can use both hardware and virtual devices... don't know exactly how aTc set it up.

Can that be done via Alsa/pulseaudio settings or is that something to be done in the config files? I'm fine with both, just need to know which and where

No, you need to poke some registers to activate / deactivate streams.
That's also one important thing: Even if you mute audio, the stream itself is enabled. So muting the speakers or headset does not does not switch off the stream. So at the moment, we have multiple streams (microphone, headset, speakers) which are running at 96kHz at the same time.
So yeah, there's a lot that eats CPU power and can theoretically create noise on a channel.
 
No, you need to poke some registers to activate / deactivate streams.
I seem fail to finding those settings.
I think in the pulsaudio setting there is no on/off switching of the streams
in Alsamixer there are some you can only mute and some you can switch to "off" I did switch off all that can be there. (no effect there)
So I might oversee the obvious where to switch off the streams.
 
I seem fail to finding those settings.
I think in the pulsaudio setting there is no on/off switching of the streams
in Alsamixer there are some you can only mute and some you can switch to "off" I did switch off all that can be there. (no effect there)
So I might oversee the obvious where to switch off the streams.
You don't have any such settings. As said: You need to poke the registers of the audiochip directly by using a tool to change registers at certain addresses.
Something like that could be implemented in the driver so it's easier to switch them on/off via userspace, but at the moment, you can only do that by directly poking registers in the chip.
 
  • Like
Reactions: rSl
so if someone could create a proper daemon from that, it should improve a lot.
That IS a proper daemon. You start it , it works, done.

atcs problem with that is merely his dislike of my coding style.
 
  • Haha
Reactions: rSl
Back
Top