It's the details that take longest (Part 3)

[TeDaDeS]

I believe ED can do the audio testing for sure, but note that the circuitry needs to be tweaked to get best results.

Due to the new design of the Pyra, and probably a different DAC, you also need to redesign some parts of the pandora audio concept.

On the DAC side, if you ignore specs, people just have different taste about what sound is preferable. The Pandora DAC had a warm sound, might even measure worse when seeing the signal coming by (while exact signals might sounds harsh and digital).

But ED knows all that, so that part will be fine.

The tweaking of the hardware however (measuring ground loops, noise, having clear clock) is something that has to be done on the board side, after the DAC is already in place.

 

[ssokolow]

Best explanation I've found for why anything beyond 48KHz audio is actually counter-productive:

24/192 Music Downloads ...and why they make no sense by Monty from Xiph.org

TL;DR:

• 96KHz and 192KHz sampling rates are spectral padding to allow for the limitations of low-pass filters built from analog electrical components.
• They're more likely to cause distortion during playback by causing the speakers to react in unintended ways to the supersonics.
• Confirmation bias and the placebo effect are powerful in this space. If you didn't do a double-blind test on yourself using one of these free ABX-testing tools, your opinion isn't worth the time it takes to share.

Yes, I do remember reading a Scientific American article a decade ago which talked about how, while we can't directly perceive them, recording and reproducing supersonics produced a sense of greater realism... but that required the researchers to use special recording equipment and special speakers... neither of which are going to be involved in the process of you playing back a typical commercial 192KHz audio file.

 

[vinipsmaker]

24/192 Music Downloads ...and why they make no sense by Monty from Xiph.org

There is the video version: https://www.xiph.org/video/vid2.shtml

 

[ssokolow]

24/192 Music Downloads ...and why they make no sense by Monty from Xiph.org

There is the video version: https://www.xiph.org/video/vid2.shtml

No, that's a good video, but it just expands on part of the blog post. He basically says that within the first minute of the video. (The first in the series covers another part of that blog post but even both parts together don't cover the whole thing.)

 

[mcobit]

Wifi components produce a really annoying sound if your amp/cables/taces are not shielded properly.

 

[klapse]

I use the pandora as my primary music player hooked up to amplifiers operating at 100% volume. No pops or clicks when using a USB hard drive.

I do however hear 50hz hum, especially when the power supply is connected.

The hum decreased when I switched to a more expensive 1/8"-RCA  cable.

 

[benoitb]

The Marvell 88W8797 (datasheet) might be another option for Wifi. There seem to be versions with USB and SDIO interfaces and the driver is GPLed and already part of the linux kernel (while still requiring a firmware blob). Since it's used in the Surface Pro 1&2, it would be reasonable to assume that the driver is somewhat well-tested, like the Realtek / Broadcom chipsets. Also comradekingu already mentioned it, along with some other options.

Well, so far all WiFi systems (TiWi, RealTek, Marvell etc.) need a binary firmware blob to operate. And all of them have a GPLed kenrel driver (which downloads the firmware and does some special stuff above the standard SDIO interface).
Otherwise they differ in:


* cost


* dimensions


* interface to CPU (e.g. 1.8V vs. 3.3V SDIO), battery and other parts


* availability (to us)


So far the Jorjin module is the best in these categories. Therefore, if we have to choose between systems requiring a binary blob (and it looks as if we have to) it is the best one we can currently get. But there may be something even better.

Can the currently selected module be used in monitor, master and client modes ? I like to have the flexibility to create an AP with hostAP and generally tinker with wifi. It would be good to have a module that has a good driver supporting these features.

I see it is a dual band chip (2.4GHz and 5GHz), which is good news. In terms of antennas, I guess it will be 1 antenna ?

 

[Guest]

I don't want to have to use Wayland, as I was planning to port CDE to the Pyra.


I don't mind binary blobs, but if they mean X11 can't be used, then maybe you should try writing your own.

Wayland supports X11 emulation via the XWayland server. Right now it's pretty flaky (both in compatibility and performance), but it's bound to improve as Wayland matures. There's no technical reason for it to be slower than native X11 - only lack of manpower to make it so.

I expect it to be production-quality at the time Pyra hits the market.

I think only applications are supposed to be supported by XWayland, not window managers. And aside from that, compatibility is quite good, actually.

There is no reason why an X11 window manager couldn't run under XWayland and manage other X11/XWayland clients. There is no way for it to manage native Wayland clients - but if you intend to create a full X11-only environment, that should not be a problem.

And yes - normal X11 applications already run pretty well under XWayland. The flakiness appears around more specialized corners of X11 like window management, EWMH, etc.

Wayland is a protocol i.e. equivalent to the X11 protocol

A compositor such as Weston provides the equivalent of the X server and X window manage. XWayland is a X server implementation provided with Weston and there is a built in x window manager.

You could run Xnest and then use your on window manager.

Weston can use pixman rather 3D HW compositing. Clients can still use 3D HW.

Many of the popular toolkits have Wayland support with several desktops with close to production ready compositors.

 

[trololololo]

I don't want to have to use Wayland, as I was planning to port CDE to the Pyra.


I don't mind binary blobs, but if they mean X11 can't be used, then maybe you should try writing your own.

Wayland supports X11 emulation via the XWayland server. Right now it's pretty flaky (both in compatibility and performance), but it's bound to improve as Wayland matures. There's no technical reason for it to be slower than native X11 - only lack of manpower to make it so.

I expect it to be production-quality at the time Pyra hits the market.

I think only applications are supposed to be supported by XWayland, not window managers. And aside from that, compatibility is quite good, actually.

There is no reason why an X11 window manager couldn't run under XWayland and manage other X11/XWayland clients. There is no way for it to manage native Wayland clients - but if you intend to create a full X11-only environment, that should not be a problem.

And yes - normal X11 applications already run pretty well under XWayland. The flakiness appears around more specialized corners of X11 like window management, EWMH, etc.

Wayland is a protocol i.e. equivalent to the X11 protocol

A compositor such as Weston provides the equivalent of the X server and X window manage. XWayland is a X server implementation provided with Weston and there is a built in x window manager.

You could run Xnest and then use your on window manager.

Weston can use pixman rather 3D HW compositing. Clients can still use 3D HW.

Many of the popular toolkits have Wayland support with several desktops with close to production ready compositors.

XWayland is a Wayland client and an X11 server. In other words, X11 apps are sandboxed away from native-Wayland apps. The Wayland server knows nothing of X11 clients. From its point of view, there is a single app (XWayland) creating and owning all those windows, which in reality belong to multiple X11 apps.

XWayland can leave window management to the Wayland server, or it can request unmanaged windows and manage them on its own (delegating that to an X11 WM client). Again, this is opaque to the Wayland server, which is just seeing a single client that requests and then handles unmanaged windows.

Xnest is an option, but it is unnecessary, as XWayland is a nested X server all by itself.

 

[Silent-Hunter]

Won't that reduce performance when running X11 stuff? Most programs are X11, so we should probably use that if we can.

 

[vinipsmaker]

Won't that reduce performance when running X11 stuff? Most programs are X11, so we should probably use that if we can.

If you care about performance, then you should embrace Wayland.

Games are more likely to use SDL and should migrate to SDL2, which does support Wayland. I've read somewhere that there was a plan to reimplement SDL in terms of SDL2, then it'd support Wayland (and other goodies) too.

 

[Silent-Hunter]

I mostly care about things working the way I'm used to, and I am used to X11. If I can compile an X11 application and have it just work with Wayland, then I suppose it's fine, otherwise I think it's a bad idea.

 

[vinipsmaker]

I mostly care about things working the way I'm used to, and I am used to X11. If I can compile an X11 application and have it just work with Wayland, then I suppose it's fine, otherwise I think it's a bad idea.

Yeah, I agree with that. There is no rush to migrate to Wayland, but then you're using performance as an argument in favour of X11..

 

[Silent-Hunter]

I was referring to possible performance loss when running X11 programs under Wayland, programs that can ONLY run under X11.

 

[neko]

Well, so far all WiFi systems (TiWi, RealTek, Marvell etc.) need a binary firmware blob to operate. And all of them have a GPLed kenrel driver (which downloads the firmware and does some special stuff above the standard SDIO interface).

What about Atheros? No blobs. I don't know if they offer a SDIO interface though.

 

[DAP]

Reasons for higher than 44.1kHz sampling:

For Nyquists sampling theorem to work, one must have a perfect brick wall filter and 1/2 the sampling rate. This is impossible. This is why the sampling rate is 44.1 kHz, not 40 kHz.

Filtering can be done much more accurately (and orders of magnitude cheaper) in the digital domain than in the analog domain.

So the idea is to use a higher sampling rate (96 or 192 kHz), do the 20 MHz low pass filter in the digital domain, and use a much simpler and cheaper low pass filter in the analog domain.

The digital filter and the higher sampling rate guarantees there is no energy in the 20 MHz to Nyquist frequency range, so you get the same quality for less money, in a smaller package.

 

[CFWhitman]

Reasons for higher than 44.1kHz sampling:

For Nyquists sampling theorem to work, one must have a perfect brick wall filter and 1/2 the sampling rate. This is impossible. This is why the sampling rate is 44.1 kHz, not 40 kHz.

Filtering can be done much more accurately (and orders of magnitude cheaper) in the digital domain than in the analog domain.

So the idea is to use a higher sampling rate (96 or 192 kHz), do the 20 MHz low pass filter in the digital domain, and use a much simpler and cheaper low pass filter in the analog domain.

The digital filter and the higher sampling rate guarantees there is no energy in the 20 MHz to Nyquist frequency range, so you get the same quality for less money, in a smaller package.

The problem with this theory is that digital filtering requires less headroom than analog filtering. That is, 44.1 kHz is enough for analog filtering, but it's more than enough for digital filtering. The higher sampling rate has even less benefit if you use digital filters. (Edit: Technically, it can't have less benefit than none; in reality it's just further above the highest sampling rate that will have benefit.)

 

[Eight Bit]

Cool. You should test this interesting Kickstarter Project around the PONO High Quality Audio player that promises lossless Music quality, even higher than CD.  This device seems to be compared expencive for an "iPod like" music player and they promise alot. But I like the idea actualy.

This would probably be a good time to mention that the human ear is incapable of hearing sounds higher than a fraction above 20kHz, and due to the sampling theorem, the highest sampling frequency needed for processed audio is 40kHz (44.1kHz is often used)

Consumer recordings or playback equipment up in the hundreds of kHz are just silly, unless you plan to do heavy digital processing.

Though it's true that the >20kHz frequencies aren't audible, the digitally stored waveforms of (especially) higher frequencies under 20 kHz will look (and thus sound) a lot better on 192KHz than they ever will on 44.1KHz. As you can imagine drawing a 20kHz sinus with only 2 points to draw it with won't make a nice sinus at all

 

[comradekingu]

Oversampling depends on how its done, could be worse, could be better.

Frequencies in domains that arent audible will still ripple per octave out into the audible register. But that is already a mostly moot point, since you can record sound with echo already in place.

Regular recording equipment isnt much better than the human ear anyway, so maybe in the future someone will make use of it to really design the soundstage, or vary it in things like games.

 

[slaeshjag]

Cool. You should test this interesting Kickstarter Project around the PONO High Quality Audio player that promises lossless Music quality, even higher than CD.  This device seems to be compared expencive for an "iPod like" music player and they promise alot. But I like the idea actualy.

This would probably be a good time to mention that the human ear is incapable of hearing sounds higher than a fraction above 20kHz, and due to the sampling theorem, the highest sampling frequency needed for processed audio is 40kHz (44.1kHz is often used)

Consumer recordings or playback equipment up in the hundreds of kHz are just silly, unless you plan to do heavy digital processing.

Though it's true that the >20kHz frequencies aren't audible, the digitally stored waveforms of (especially) higher frequencies under 20 kHz will look (and thus sound) a lot better on 192KHz than they ever will on 44.1KHz. As you can imagine drawing a 20kHz sinus with only 2 points to draw it with won't make a nice sinus at all

With a very simple output filter that should be there anyway, it'll look a lot nicer. Nyquist, etc..