Keep cool!

[kabaiakh]

My dirty mind thought though ...

Spoiler

Pyra could be used as Rabbit replacement !!!

 

[Binky]

You mean we could feed it vegetables instead of using a USB charger?
Sounds like a great idea!

 

[kabaiakh]

You mean we could feed it vegetables instead of using a USB charger?
Sounds like a great idea!

 

[Splintercat]

I honestly haven't had an issue with Pulse Audio for years, and I regularly take advantage of its ability to allow me to adjust sound output by application, and switch input and output devices on the fly.
Not saying people have not or still don't have issues using it. Take it with a grain of salt, but in an interview with Lennart Poettering he chalked up to many of the problems Pulse has had is from using little or unused driver features, or misbehaving applications.

I'm looking forward to being able to easily use a bluetooth headset with my Pyra.

 

[Swordfish II]

Pulseaudio is terrible on the raspberry pi. Constant issues with it

 

[neko]

No, shielding shouldn't be needed here.

Does the aluminum plate affect the wifi signal?

 

[TrashyMG]

Does the aluminum plate affect the wifi signal?

I don't believe so, If I recall properly the Wifi antenna will be routed through to the LCD lid. From the shape of the cutout It looks like it won't cover the Cellular antenna either.

 

[Black Sliver]

I honestly haven't had an issue with Pulse Audio for years

Besides not using available hardware power (for mixing), the only problem with pulse right now is the magic buffer™, that's not going away. Streaming a pulse stream over network or from one device to another (e.g. capture card in -> onboard out) will/may induce an increasing delay, I guess because of sample rate mismatch. At least with ALSA, the supported features did work as expected; nowhere near the "official drivers" (e.g. windows) though.

Edit: people (including me) should really stop hijacking threads for PA "discussions"
On-topic: It's nice that the vibra-motor has a "regular" DAC channel and is working

 

[Wally]

Exciting news, can't wait for release day

 

[Swordfish II]

Exciting news, can't wait for release day

I read this and initially thought it said "release delay" lol

 

[Wally]

I read this and initially thought it said "release delay" lol

Two Months™

Let's hope ED doesn't get eaten by the shark in my avatar

 

[trix]

that looks more like pacman-on-a-stick than a shark IMO.

Also, great news! I don't have enough cash yet so take your time lol.

PS.
The thread is called Keep Cool! But I have the opposite problem -- I live where it is often extremely cold. Unfortunately, I don't seem to stress my Pandora enough to use it as a portable hand warmer. Hopefully the Pyra can warm up my hands without burning its innards.

I mean yes, there are much cheaper ways to keep my hands warm, but they are less fun than playing castlevania or something on my smoke break.
[doublepost=1500986447,1500985888][/doublepost]Ok Wally I just spent five straight minutes watching your "shark" try to eat that person repeatedly.

I'm not sure why. I do know I really want the shark to succeed though.

 

[guacamole]

Amazing, two more months™ then!

 

[Letalis Sonus]

I honestly haven't had an issue with Pulse Audio for years, and I regularly take advantage of its ability to allow me to adjust sound output by application, and switch input and output devices on the fly.

Try using it with audio hardware that does not follow the traditional desktop 2.0/4.0/5.1/7.1 output layout, for example - you'll have lots of fun. PulseAudio can be a real configuration nightmare if you're leaving the holy path of the desktop defaults - and I don't want to know what kinds of "litte or unused driver features" Poettering would argue with when confronted with the issues that follow.

Coincidentally, that's exactly what you're dealing with on a lot of embedded devices like the Pyra: You have dozens of channels, and they neither start with channel 0/1 for stereo output nor are all being used just for audio. The channel mapping should be fixable with the underlying ALSA config and a small modification of the Pulse config, but using channels independently that are attached to the same controller? I don't even know where to start to get this to work with Pulse... If you want to control e.g. the vibration motor through this and can't find some hacky way to get it to work with Pulse (and you don't want the access to be exclusive by just accessing the ALSA hw interface directly) then we're talking about throwing dmix into the mix - yo dawg, I heard you like mixers, so we put a mixer under your mixer!

That gives me an idea, though... can't we use the DSP as a hardware mixer for the audio controller?

 

[sebt3]

But I have the opposite problem -- I live where it is often extremely cold. Unfortunately, I don't seem to stress my Pandora enough to use it as a portable hand warmer.

If you want to turn your pandora as hand warmer, try this : https://pyra-handheld.com/boards/threads/cpu-stress-test.68361/
it's very effective.
On the pyra side, while it's possible to have it as handwarmer while doing heavy duty (like compiling), it never got unconfortable for me

 

[Black Sliver]

That gives me an idea, though... can't we use the DSP as a hardware mixer for the audio controller?

Afaik that's the goal on "HW-level" (channel mapping + resampling) but has still driver issues. On the other hand, leaving channels as they are up to userspace would have the benefit of being less confusing... not sure what the exact plans are.
The userspace mixing will always be done in userspace, as PA did not support hardware mixing last time I looked.

 

[Letalis Sonus]

(channel mapping + resampling)

I do mean mixing as in mixing multiple audio streams together, that's ALSA's understanding of a hardware mixer ([HWMIX] hardware tag in their wiki).

I used to have a Turtle Beach card with a DSP-backed hardware mixer, it's rather nice not to use dmix or Pulse at all - too bad the additional surround channels were realized with a separate audio codec, which didn't work very well with the DSP firmware they provided for Linux. My current card can pretty much only use its stereo hardware mixer for mixing its input channels into its output channels, but it's great for avoiding Qemu's glitchy emulated soundcards...

 

[Black Sliver]

If you think about per-application transitions from handset to handset and maybe to blue tooth, PA is the easier choice. You'd need something like PA (= virtual "default" ALSA device) with HW mixing support and configuration interface for that.

I believe having two "OSS" sinks that get mixed in-hardware would be possible on most SoCs, but someone would to configure or write the firmware for that...

 

[Letalis Sonus]

If you think about per-application transitions from handset to handset and maybe to blue tooth.

I'm thinking about plain hardware mixing for the internal DAC, I personally don't care about Bluetooth (or any external audio hardware in general) at all.

I believe having two "OSS" sinks that get mixed in-hardware would be possible on most SoCs, but someone would to configure or write the firmware for that...

ALSA natively supports hardware that accepts more than one stream per device, it just needs to be hooked up into the audio driver. The access on ALSA's HW interface will simply be non-exclusive until the driver runs out of available mixing channels.

 

[Black Sliver]

ALSA natively supports hardware that accepts more than one stream per device, it just needs to be hooked up into the audio driver. The access on ALSA's HW interface will simply be non-exclusive until the driver runs out of available mixing channels.

I know. That's what we used to do before PA. But you'd need an ALSA driver for that -- two OSS devices are easier to explain.