Many little steps

[Jumpman]

Looking AWESOME!

I can't wait for some killer videos running emu's and looking sweet! Kudos to ED and his "League of Extraordinary Gentlemen", you guys are really doing great work, the Pyra can't ship soon enough.

Chris

 

[___]

Awesome as always.
About the audio : is it cleaner or louder than the previous video ? Even though the mic didn't do it justice, I thought it was the best in frequency restitution. All it could lack would be a bit of warmth, but I'm only guessing from the video.

well... if those are neumann mics, as I think they are, then they are certainly not at fault ^^. more the recording situation.

@EvilDragon out of personal interest, what kind of setup did you use to record that soundtest?

EDIT: Tried to find some reference pictures. Sure does look like neumann mics. Now I am really excited to hear what you've got (pun intended ^^)

 

[EvilDragon]

They were Sennheiser, but not the best ones for the recording (more meant to record voices than music).
I got a better Sennheiser now, a pretty much linear one

 

[___]

dang... I was pretty sure it wasn't sennheisers. two neumann mics would've been awesome. anyway, I am sure your mics are top notch. but regardless of how good the mic used, a recording like this can never come even close to what we'd actually be hearing.

 

[Silent-Hunter]

So how will the touch panel from the Pandora fit the Pyra? Isn't the Pyra's screen bigger?

 

[comradekingu]

You can get pretty close with a binaural recording.

Sensitivity is the deciding factor, provided normal operation, of how loud headphones are.

Unless you want the top end to be too loud, you can set the gain-level for the amp.
There is also a max volume setting alsa, but i didnt get it to work the one time i tried it.

 

[Yoyobuae]

So how will the touch panel from the Pandora fit the Pyra? Isn't the Pyra's screen bigger?

I also asked the company that made Pandoras touchscreen whether they can use the exact same material for the Pyra touchscreen. No answer yet, but as soon as I get one, I'll let you know.

New touchscreens with same material, but different size need to be made. The company which made Pandora's touchscreen needs to agree to produce them, though.

 

[Klumpen]

Threads like this one improve this sad old man's life.

Having Pyra touchscreens with the old material would be grand,
seeing the problems in the production process now, I'm even more impressed/surprised how well the Pandora turned out to be in spite of the many severe production problems.

 

[levi]

Will that TILER thing also be able to do the trick for the HDMI out?

That's a question worth repeating. I suspect, since he's working on a devboard connected to a screen, this is actually rotating the HDMI out at present, and hopefully it's just a matter of switching the target to make it rotate the LCD out instead.

I do still wonder if it'll be possible to rotate both displays independently (you'd want the internal LCD to be rotated, but normally not the HDMI out). I do have a screen mount that does allow the screen to be switched edge on, but you don't want a simple rotated 16:9 framebuffer for that, you want the OS to configure a new 9:16 framebuffer, render to that and then rotate it, so that when the screen unrotates it by virtue of being on its side, text it still the right way up.

 

[ible]

yeah, typically you don't need to rotate the HDMI, unless you've rotated your screen... but perhaps that is desired to play something like ikaruga

 

[rSl]

another yay for progress!!!

and please ed, always remember, health really is top priority.
not only for you personally, also for the whole project/community thingy.
so all the best for your... rest!

 

[rygD]

yeah, typically you don't need to rotate the HDMI, unless you've rotated your screen... but perhaps that is desired to play something like ikaruga

I also flip to portrait when typing or looking at a lot of books and such. It would probably also be great for some web content (like certain threads here with rather long posts).

 

[zmatt]

I like how the screen is forcing you to get the rotation to work, unlike the Pandora, where rotating the screen simply doesn't exist

Weird, I haven't looked in detail but I think I've seen stuff for the omap3's rotation engine (VRFB) in kernel as well. But I guess maybe noone took the effort to make all the ingredients work together properly for the desired end result?

Will that TILER thing also be able to do the trick for the HDMI out? Rotating the screen is awesome for coding, it would be sad if that doesn't work.

That's a question worth repeating. I suspect, since he's working on a devboard connected to a screen, this is actually rotating the HDMI out at present, and hopefully it's just a matter of switching the target to make it rotate the LCD out instead.

Actually mostly my effort has been on fixing slowness of cpu access to buffers allocated in tiler memory, or (in this case) getting buffers to be allocated in tiler memory in the first place.

Once the framebuffer is there I know (and have verified) that DSS can scan it out in any orientation. Its rotation can be changed with one flip of a switch (or rather one DRM_IOCTL_MODE_ATOMIC setting the "rotation" property of the relevant layer):
(Yes, I managed to fix the stride issue with mmap()ing the fbdev At least, if you don't mind the kernel oopses.)

Making the rotation happen by default for the built-in lcd screen (invisible to userspace) would be the finishing touch, and mostly just requires the kernel to meddle a bit with metadata to lie about the true dimensions and orientation.

I do still wonder if it'll be possible to rotate both displays independently (you'd want the internal LCD to be rotated, but normally not the HDMI out).

Yes. Specifically DSS supports 4 layers (total, not per output) that have independent buffers, pixel format, rotation/mirroring, scaling (for 3 of the layers), cropping, positioning, and z-order relative to other layers on the same output. Every layer can have an alpha channel and each output has a configurable solid background color (default black) to deal with pixels not covered by any fully opaque layer.

I do have a screen mount that does allow the screen to be switched edge on, but you don't want a simple rotated 16:9 framebuffer for that, you want the OS to configure a new 9:16 framebuffer, render to that and then rotate it, so that when the screen unrotates it by virtue of being on its side, text it still the right way up.

You mean exactly what xrandr --rotate does?

For ±90-degree rotation you'll always need to reconfigure the framebuffer dimensions since a 16:9 framebuffer rotated 90 degrees obviously does not fit on a 16:9 display. This is also plainly visible in my demo above (where I just positioned it randomly for fun). That's also why I mentioned the need to lie about the true dimensions of the screen to finish things off: fbdev needs to allocate and advertise a 1280 x 720 framebuffer, so that when rotated it'll fit neatly on the 720 x 1280 display.

 

[Caine]

@zmatt

Kerel, goed bezig!

 

[zmatt]

Some audiophile headphones require a much higher impedance to be driven to acceptable volumes.

You mean "have a much higher impedance, requiring higher voltage (but less current) to be driven to acceptable volumes."

If the Pandora and its successor are able to drive them, that would mean much higher volumes for more common headsets.

Ideally a volume knob would scale the power delivered rather than voltage driven. Unfortunately that's easier said than done...

 

[comradekingu]

There is no necessity of impedance speaking for sensitivity.

Seeing as the impedance isnt linear, scaling power is a bad idea, but again not by neccesity. You can operate the voltage at the same level and dial down current, which has some benefits, but not to the issue at hand. Also i think that is patented.

For bluetooth headphones you can communicate sensitivity, for headphones you would have to do a frequency sweep and measure the unique differences seen by the amp, which at worst is only power overall, at very slow sample-rate.

So its still software volume limiting, or even worse, a compressor. Or you are down to setting gain.

Doing it in hardware is a possibility, doing it in software, atleast in one option means extra cpu cycles.

You can do so given a measure of the most sensitive headphones, and then prompt the user to unlock should more be needed. I think this is required by the EU, you may have seen it in some devices.

 

[zmatt]

To clarify, I wasn't being very serious. The necessary current measurement would already need to be implemented in the amplifier, and I have no reason to assume it is.

There is no necessity of impedance speaking for sensitivity.

The topic was however the concern of the large range in headphone impedance and its obvious impact on sensitivity. Of course it is not going to be the only factor; perhaps the "headphone" is actually just a pair of resistors used as active ear-warmers, it would be hard to say for sure (although it would result in a suspicious-looking impedance curve when plotted against frequency).

Seeing as the impedance isnt linear,

linear in... what?

scaling power is a bad idea, but again not by neccesity.

???

You can operate the voltage at the same level and dial down current

Eh, no you can't. Please go back to electrical engineering 101.

you would have to do a frequency sweep

I would expect music to be sufficiently broadband to allow for reasonable estimation of the impedance curve. This would however require high-quality feedback measurement and a non-trivial amount of computation. (It also seems like overkill for the purpose of just estimating the nominal headphone impedance. On the other hand I've only once seen real-time impedance estimation implemented, and it was on a DSP board attached to an amp with audio-quality voltage and current feedback measurement. Given what I said at the top of this post I see little point in spending more thought on it really.)

 

[levi]

Just give me a wheel with plenty of range so that I can do the computation in my head to decide whether I need my music to be louder or quieter.

 

[comradekingu]

So you see a value from the amp which you can drive, whether by current or voltage drive, it from the same element operates for the purpose of sensitivity in a predictable manner, but, it is not derived from the impedance between different elements. Whether by simple current limiting or voltage limiting, there are less issues with resistive loads, it still gets us no further towards the point.
Even if you have a perfect plot of the impedance graph, you still need a lookup table of known measurements to compare it to.

Otherwise its sort of works-guesstimates, which can be worst (best) case sensitivity, or operating on a non-exact correlation.

Levi: Luckily the stepping of the range isn't predetermined.

 

[Xcl4m4t10n]

Thank you for the news @ED and thank you for the reports and information @zmatt, well done!