Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
An argument against using cross compilation.
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM
View previous topic :: View next topic  
Author Message
crocket
Guru
Guru


Joined: 29 Apr 2017
Posts: 449

PostPosted: Sun Jan 05, 2020 4:02 pm    Post subject: An argument against using cross compilation. Reply with quote

crossdev packages broke after upgrading gentoo profile from 17.0 to 17.1. Cross compilation is not yet a first-class citizen in portage or emerge. Rather than using crossdev, emerge should integrate it.

It really helps to buy an ARM build machine if you want to use gentoo on ARM single board computers. Keep things simple and stupid.
Back to top
View user's profile Send private message
erm67
l33t
l33t


Joined: 01 Nov 2005
Posts: 647
Location: EU

PostPosted: Mon Jan 06, 2020 3:23 pm    Post subject: Reply with quote

Did you also consider that compile everything on ARM is really useful if gcc can take advantage of the optional CPU features (fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid) so to avoid crosscompiling the arm build machine will have to support the same optional CPU features? And that if your CPU doesn't support any optional feature and -O2 is the only optimization flag you are allowed to use probably a binary distro will be faster?
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia

My fediverse account: @erm67@erm67.dynu.net
Back to top
View user's profile Send private message
crocket
Guru
Guru


Joined: 29 Apr 2017
Posts: 449

PostPosted: Mon Jan 06, 2020 10:49 pm    Post subject: Reply with quote

I can worry about binary optimization later. For now, maintenance cost is the biggest cost. I don't use gentoo purely for binary speed. Compiling almost everything confers flexibility of configuration, too.

For example, I don't think firefox without pulseaudio and torbrowser without pulseaudio are possible in binary distributions.

It gives me freedom to avoid programs I don't like such as pulseaudio and systemd. I tried to like pulseaudio, but it is really opinionated, and its automatic configuration pisses me off when I want to set up my audio system manually. And, pulseaudio's automatic port configuration is broken.
I don't want to fix a broken system with my scarce time. ALSA has bugs, but I can easily work around them because it doesn't configure itself automatically. Do I want to learn a programming language and haggle with pulseaudio developers? Hell, no. I don't want to abuse myself by putting myself through the wringer called pulseaudio developers.
Systemd often hung during shutdown. I didn't like that, either. Systemd developers refused to fix the hanging issue during shutdown because it is other programs that are broken, not systemd. I don't want to deal with them to fix the issue, either.

A software that works is far faster than a software that's broken. The big optimizations are done by using better softwares which don't have issues or allow me to work around issues. I can care about little optimizations around CPU flags later.
Gentoo is the minimal distribution that I could use because it allows me to avoid dealing with broken softwares and people with big fat ego behind those softwares.
Otherwise, I would be using arch linux or artix linux right now.

If you were worrying about not being able to share CPU flags among single board computers, you could make each single board computer a self-building machine. Why can't native gcc compile binaries with CPU flags the CPU doesn't support? That can be possible in chroot for each respective single board computer without cross-compilation.
Back to top
View user's profile Send private message
erm67
l33t
l33t


Joined: 01 Nov 2005
Posts: 647
Location: EU

PostPosted: Tue Jan 07, 2020 10:20 am    Post subject: Reply with quote

This might be an argument on a PC, even if I doubt that someone that cannot configure pulseaudio or systemd can instead configure ALSA or openRC, maybe they come with defaults better for them ......... maybe you only have a PC with onboard sound card and a couple of PC speakers of questionable quality connected but a lot of people demands a lot more than that.
On a ARM board that ATM cannot be really used as a desktop (hopefully that will be fixed in the near future) it is not really an argument, pulseaudio however can be useful since there aren't really better alternative to stream sound in linux. Coreelec comes with a preconfigured pulseaudio, shairport and optionally snapcast, and well currently pulseaudio is what works better in linux .... the other protocols are based on reverse engineering, probably patented, pulseaudio is a native linux solution that works well. So if you want to use your ARM board as a media server, it might be an excellent choice. Unfortunately pulseaudio defaults are not the best for all situations, in fact what you call automatic configuration are just default values, that might not be the best for your hardware. If you have some links to the source code of pulseaudio that performs this autoconfiguration that you are imagining I'd be very happy to browse it.

I always used openrc on the gentoo server, because you know why :-) but recently I recently switched to systemd .... it is a lot better, if the openrc guys spent less time boosting their big ego and more time fixing problems it would be better :-) one of the reason was Link Aggregation Groups, I know I can manually setup and debug that with openRC but it was the final drop for me. I understand that for someone that depends on questions asked on forums and copy/paste from tutorials the only option is to follow the nearest sheeps and do what the others do. A lot of modern linux user are just very good at copy-pasting from the internet :-) in a era where internet is full of fake news it can have terrible effects.

https://www.phoronix.com/scan.php?page=news_item&px=Debian-Devs-Vote-For-Prop-B
Also Debian recently decided that the default init system will be systemd, other init systems will be supported but their developer will have to develop them and adapt them to Debian not the opposite. Considering the improvements that I experienced in the latest years with openRC I am pretty sure systemd is the safest choice, all they can do is pretend that other people fix their problems.


BTW archlinuxARM is a separate entity from Archlinux but is really an excellet distro for arm boards.
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia

My fediverse account: @erm67@erm67.dynu.net
Back to top
View user's profile Send private message
crocket
Guru
Guru


Joined: 29 Apr 2017
Posts: 449

PostPosted: Tue Jan 07, 2020 12:14 pm    Post subject: Reply with quote

You think pulseaudio is easier. I used to think so, too. The reality is counter-intuitive.

It wasn't just pulseaudio default. I tried to manually configure ALSA mixer controls, but pulseaudio port system overrode it whenever I tried to configure ALSA mixer controls manually. Pulseaudio couldn't configure my onboard soundcard correctly. I could have written pulseaudio support for my hardware, but ALSA was far simpler than that. Let's face it. Automatic configuration cannot account for an infinite list of every possible hardware. Checking off an infinite checklist will take forever. Even if there is only a limited number of hardwares, there is infinite possibility for future hardwares. Infinity is a bitch. Sometimes, a manual configuration involves less hassle. Sometimes, an automatic configuration can be better. When automatic configuration doesn't work, it interferes with manual configuartion. So, I prefer manual configuration when automatic configuration doesn't work.

Also, pulseaudio is not designed to maintain low latencies necessary for lip sync while CPU cores and HDDs are under full loads. For months, I fiddled with low latency audio. jack was okay, but it doesn't work with web browsers and various applications. I tried bridging various audio systems with each other, but it was awkward. They don't really integrate well with each other under heavy loads incurred by kernel compilation and gentoo upgrade. I tried pulseaudio, JACK, and ALSA for months. ALSA was the last remaining survivor in my simple audio steup.

If you want a lot more control than ordinary linux users, automatic configuration can get in the way. With ALSA, I was able to manually configure latencies and measure xruns. I understand that most people should just use pulseaudio when it's given as a distribution default. But, it's not for me. I want the control that ALSA gives me over audio. When I want control, ALSA is simpler. JACK can be simpler than ALSA, but it is not supported by many applications. If your headphones are plugged into a USB DAC and your speakers are plugged into onboard soundcard, I cannot make pulseaudio switch between headphones and speakers, or it's very difficult to figure out how to do so because pulseaudio is a complex automatic system designed to work automatically for most users in the most common use cases. Pulseaudio doesn't account for uncommon use cases. Tweaking it is far more difficult than tweaking ALSA. In the worst case, I may have to fight or haggle with pulseaudio developers to just switch between headphones and speakers on pulseaudio. At least ALSA makes scripting easy. If you actually fiddled with ALSA and pulseaudio, you would also discover that tweaking ALSA is easier. Remember that pulseaudio is just an additional layer on top of ALSA.

systemd might have gotten better, but I have no real reason to move away from OpenRC. I'm in a comfortable place with OpenRC.

Actually, whether I choose systemd, pusleaudio, ALSA, or OpenRC doesn't matter. I could have chosen the opposite. What matters is that gentoo makes it simpler to choose and avoid softwares. Gentoo allows me to compile firefox with ALSA instead of pulseaudio. On other distributions, it would have been difficult to do so.

I don't think minimal softwares have better egos, but it is easier to make minimal softwares bend to my will so that there is less need to interact with humans. I also used runit on void linux and artix linux. Although it lacks many features I'd want in OpenRC, I can easily make it bend to my will because it is so minimal. I could probably live with systemd, but pulseaudio isn't something I would use. In the future, I may consider pipewire because it is supposed to support JACK and low latency audio.

This comment is not an argument to convince you to use ALSA or OpenRC. Use whatever you like.
Back to top
View user's profile Send private message
erm67
l33t
l33t


Joined: 01 Nov 2005
Posts: 647
Location: EU

PostPosted: Wed Jan 08, 2020 9:46 am    Post subject: Reply with quote

Still I don't see the link to the code in pulseaudio that performs this automagic reconfiguration of alsa devices, :-) But the problem is that ALSA and pulseaudio are 2 different things, ALSA is the framework used to write drivers for sound cards in linux while PulseAudio is a general purpose sound server intended to run as a middleware between your applications and your hardware devices, either using ALSA, OSS, ffado.
JACK (JACK Audio Connection Kit) is a middleware for audio applications to communicate with each other and with audio hardware either using ALSA, OSS, ffado or sndio (in theory).

It doesn't make sense to say that you use ALSA instead of PulseAudio, someone might think you are a bit confused since it is impossible to use PulseAudio without ALSA.

So speaking of alternatives:
it is correct to say that you use ALSA instead of OSS instead of ffado since they are all frameworks that let you access directly the sound card hardware
it is correcto to say that you use PulseAudio instead of Jack instead of sndio since they are all middleware (sound servers) between application and low level drivers or network sound devices
On top of that there is network, you know everybody has smart speakers or some sort of networked sound devices now so on top of that you need another middleware to connect devices over the network, PulseAudio Jack, shairport-sync, forked-daap, snapcast,various UPNP renderers like upmpdcli.

Sound Servers like PulseAudio, JACK, sndio instead let various application running on your computer use the low level drivers (see above) at the same time and this means that there must be a way to mix sounds from various sources together, either using native mixing routine inside the sound server or using dmix a software mixer provided by alsa or using a hardware mixer.

Now mix sounds with different sample rate and bit depth together involves resampling the various sounds using lossy algorithms more or less good, also digitally controlling the volume in software involves an alteration of the original digital samples with a possible loss of quality. A lot of soundcards have so called hardware mixers but recent sound cards resample everything if the mixer is used or convert it internally to different format. It is possible to bypass that on most cards but it means that only 1 application at the time can use the sound card or the network speaker and the volume is always 100%. That is however the only way to play music bit-perfectly,and it is not a problem for me since my usb sound card (or DAC if you prefer) is connected to an hi-fi amplifier with the digital-direct on so that tone controls section is bypassed and I use a analog hardware knob to control the volume :-) Basically I want the sound card to just convert the samples to analog without digitally modifying them in any way.

As you can see you cannot pretend that everything is black or white, ALSA or PulseAudio ... clearly I don't want to listen to the beeps in the console bitperfetly on the hifi the laptop speakers are good for that, I also use pulseaudio since that is what gnome uses by default and software digital mixing and volume controls since I don't relly care about the quality.
Even if I wanted I could not use ALSA on my laptop to play music on the hi-fi in the living room but it goes through upmpdcli - mpd - ALSA on the N2, sometimes I play music on the laptop using DeadBeef directly over ALSA while I play system sounds using ALSA but through pulseaudio.

Some time ago (12 years ago actually) pulseaudio switched to use by default a timer-based scheduling system instead of the traditional interrupt-driven system used by ALSA, this can be turned off of course and maybe under heavy load an interrupt driven scheduling would work better. I don't think you can use PulseAudio without some sort of mixing, but there is a way to avoid resampling if possible, high quality software resampling is CPU intensive and can be problematic, no matter if it is done by pulseaudio or dmix, since also ALSA resamples everything to 48khz if using a software dmix, use a HW mixer to reduce load on the CPU. However a lot of cheap hardware mixer suck. You can also try to control the length in ms of the sound fragments to make it more resinstant to the load on the system

Why does PulseAudio use a timer-based scheduling system and resamples everything to 48khz? Easy because that is what Windows and MacOS do and a lot of hardware manufactures adaped their cards to that, recent Creative resamples everything to 48khz internally for examples since Creative engineers expects that windows sends only 48khz sounds to the card.

BTW I find the pulseaudio and systemd lunatics very funny and entertaining even if most of what they say doesn't make sense at all :-)

For lip sync usually hdmi passthrough is the best since the digital signal is sent unmodified, 'bit-perfect' to the TV, bu you have to use the other remote for the volume.
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia

My fediverse account: @erm67@erm67.dynu.net


Last edited by erm67 on Wed Jan 08, 2020 11:43 am; edited 1 time in total
Back to top
View user's profile Send private message
crocket
Guru
Guru


Joined: 29 Apr 2017
Posts: 449

PostPosted: Wed Jan 08, 2020 11:35 am    Post subject: Reply with quote

Look, I may be loose with word usage. Using ALSA instead of pulseaudio, or using ALSA without pulseaudio. I don't care. What do you want most? That's what you should care about.
Back to top
View user's profile Send private message
erm67
l33t
l33t


Joined: 01 Nov 2005
Posts: 647
Location: EU

PostPosted: Wed Jan 08, 2020 11:45 am    Post subject: Reply with quote

Well actually no matter how much do you want it but if you need a sound server you can't use ALSA directly. BTW the 2 things aren't even mutually exclusive since my sound card has a HW mixer and I can use both at the same time. So even this doesn't make sense at all :-)

People doesn't say that is stupid to say that pulseaudio is better than alsa because they love pulseaudio but because it is stupid, the opposite is not necessarily true since most people that say that pulseaudio is better than alsa out of context hates pulseaudio for personal reason and lack the technical knowledge required to understand what ALSA and pulseaudio are.

That is why most people automatically associate a phrase like "ALSA is better than pulseaudio" with the anti-X lunatics that roams internet forums.
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia

My fediverse account: @erm67@erm67.dynu.net
Back to top
View user's profile Send private message
Ralphred
Tux's lil' helper
Tux's lil' helper


Joined: 31 Dec 2013
Posts: 120

PostPosted: Wed Jan 08, 2020 9:45 pm    Post subject: Reply with quote

crocket wrote:
its automatic configuration pisses me off when I want to set up my audio system manually.

It pissed me off too, I totally get how some "everyman" config out of the box is annoying, but now mine is gimped to about 6 lines of config, and it plays nice, but I run JACK for reasons you'd never guess, so am now kinda tied to the way I've made it work.
It was an up front time investment for reasons beyond compatibility, but the ease with which clients connect to it and how I can now make pulseaudio dance to my tune are pleasing side effects.
Back to top
View user's profile Send private message
axl
Veteran
Veteran


Joined: 11 Oct 2002
Posts: 1072
Location: Romania

PostPosted: Wed Jan 08, 2020 10:10 pm    Post subject: Reply with quote

it's hard for me to understand why people try to fight pulseaudio.

because pulse audio is certainly an upgrade over alsa. as alsa was an upgrade over oss.

I think, the simple upgrade, EASY TO UNDERSTAND, is that pulse offers the ability to use more than one app to render sound. more than one at a time.

Oss cound't do that. And I think alsa can't do that still.

And the reason is that alsa is a kernel layer. and if you want to melt multiple sound streams into one, and modify volume over each stream you need a userspace app. and that's pulse.

HOW exactly people want to return to a single stream/one app prio structure... i dont understand.
Back to top
View user's profile Send private message
axl
Veteran
Veteran


Joined: 11 Oct 2002
Posts: 1072
Location: Romania

PostPosted: Wed Jan 08, 2020 10:33 pm    Post subject: Reply with quote

also cross emerge... cross compilation works great.

i'm currently watching armv6j doing emerge empty world WITH LTO.

I tested armv7a last week. after doing x86_64.

crossdev package is instrumental into making new environments. and testing them. and I think tones of people use it.

now... there's u complaining that it's stupid. it's not. really really not. it's freaking brilliant. and it works. if you don't contort it into a monstrosity, it works. it works freaking brilliantly.
Back to top
View user's profile Send private message
Ralphred
Tux's lil' helper
Tux's lil' helper


Joined: 31 Dec 2013
Posts: 120

PostPosted: Wed Jan 08, 2020 10:45 pm    Post subject: Reply with quote

But pulse doesn't behave like a userspace app out of the box, it tries to replace ALSA's userspace presence, whether it has the capability to do it properly or not, and that is where the the annoyance is.
I wouldn't be so critical of it if it would connect to virtual pcms, but it won't, so it's all or nothing unless you go JACK.
When it works it's fine, when it doesn't its a real pain in the ass because it's assumed that it will work, and it's so poorly documented.
Users have been writing dmix into .asoundrc for as long as they have been crafting XF86config files, so the software mixing argument is moot.

EDIT: yeah, crossdev is awesome ;)
Back to top
View user's profile Send private message
axl
Veteran
Veteran


Joined: 11 Oct 2002
Posts: 1072
Location: Romania

PostPosted: Wed Jan 08, 2020 10:47 pm    Post subject: Reply with quote

how can it try to replace something it is based on?

pulse works with alsa because alsa is the kernel part, pulse is the userspace part. they dont fight. they help each other ... doh.
Back to top
View user's profile Send private message
axl
Veteran
Veteran


Joined: 11 Oct 2002
Posts: 1072
Location: Romania

PostPosted: Wed Jan 08, 2020 10:49 pm    Post subject: Reply with quote

pulse doesn't work without alsa.

alsa without pulse is just single stream audio.
Back to top
View user's profile Send private message
Ralphred
Tux's lil' helper
Tux's lil' helper


Joined: 31 Dec 2013
Posts: 120

PostPosted: Wed Jan 08, 2020 10:54 pm    Post subject: Reply with quote

ALSA's userspace control apps are objectively superior to anything similar released for pulse, and pulse WILL capture your one solitary client connection to ALSA hardware, meaning if you want to DMIX, you can't, you have to go all in pulse or not use it at all, or gimp pulse through JACK the way I do.
But this is not the place to discuss where pulse is obviously found wanting, so for clarity, crossdev is cool.
Back to top
View user's profile Send private message
axl
Veteran
Veteran


Joined: 11 Oct 2002
Posts: 1072
Location: Romania

PostPosted: Wed Jan 08, 2020 10:56 pm    Post subject: Reply with quote

also, alsa is not a network service. pulse is. you can ssh into a host an move sound around with environmental values in ssh just like you push sound around with remote desktop. like leave on host, or play remotely.

alsa can't do that. pulse can.
Back to top
View user's profile Send private message
axl
Veteran
Veteran


Joined: 11 Oct 2002
Posts: 1072
Location: Romania

PostPosted: Wed Jan 08, 2020 10:58 pm    Post subject: Reply with quote

and again, you clearly dont understand. pulse doesn't replace alsa. it comes on top of alsa. you still have alsa, which was one thread one stream sound, but now you get this intermediary, that can change volume on multiple streams, play sound from network... all that good stuff from ssh unix over network stuff. multiple user. not ONE stream. still want to fight pulse?
Back to top
View user's profile Send private message
Ralphred
Tux's lil' helper
Tux's lil' helper


Joined: 31 Dec 2013
Posts: 120

PostPosted: Wed Jan 08, 2020 11:08 pm    Post subject: Reply with quote

That doesn't make it's implementation any less abhorrent, it's like saying this car is superior because it can drive on foreign motorways, but ignoring the fact it has square wheels and no brakes.
Back to top
View user's profile Send private message
axl
Veteran
Veteran


Joined: 11 Oct 2002
Posts: 1072
Location: Romania

PostPosted: Wed Jan 08, 2020 11:29 pm    Post subject: Reply with quote

i dont know what could be abhorrent about it. i'm quite fond of all these features.


having more than one source of sound, having equliser, having network sound. I don't see how these things are abhorrent.
Back to top
View user's profile Send private message
axl
Veteran
Veteran


Joined: 11 Oct 2002
Posts: 1072
Location: Romania

PostPosted: Wed Jan 08, 2020 11:35 pm    Post subject: Reply with quote

alsa is the kernel layer of sound. pulse is the userspace layer of sound. i don't see whats wrong with that. please, point it out to me.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6873

PostPosted: Thu Jan 09, 2020 2:26 am    Post subject: Reply with quote

Ralphred wrote:
That doesn't make it's implementation any less abhorrent

Compared to Dmix which is done by having everything write directly into the memory of whichever process was unfortunate enough to open the card first?
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 16472

PostPosted: Thu Jan 09, 2020 3:24 am    Post subject: Reply with quote

axl: Ralphred is criticizing the implementation, not the features offered. The features may be wonderful, but if the price in complexity, CPU time, memory, setup cost, etc. is too high, the implementation is still undesirable.

DMix has its own issues, as Ant P. noted. ALSA does have the virtue of simplicity. I've seen many people complaining that sound was broken for them because Pulseaudio got into a weird state (and restarting it was often a "solution"). I've seen people who needed to configure ALSA before they had sound (and that task can be far harder than it should be), but I don't recall reports of ALSA-based systems just suddenly failing for no apparent reason.
Back to top
View user's profile Send private message
axl
Veteran
Veteran


Joined: 11 Oct 2002
Posts: 1072
Location: Romania

PostPosted: Fri Jan 10, 2020 7:00 pm    Post subject: Reply with quote

complexity... I want a new feature, but I dont want it to be complex. like the ability to join audio streams, equalizer, setting volume on each stream. ?!

cpu time. joining 2 audio streams requires some realtime maths. it's supposed to cost cpu when you don't have a specialized audio component. if cpu and memory consumption are such a factor to audio join... maybe that person should upgrade. I don't know if computers from 20 years ago should be used for this stuff in the first place. A raspberry pi is much more affordable than running gentoo on a computer that suffocates from too much cpu usage from 2 audio streams.

Are you kidding me? Or you think I'm completely stupid? It's his close proximity to systemd that people hate about pulseaudio.

And that's fine. But don't pat yourselves on the back for living in the stoneage.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 16472

PostPosted: Sat Jan 11, 2020 1:51 am    Post subject: Reply with quote

Yes, those things should be cheap. In fact, they're so cheap that DMix can do some of them while borrowing a thread in whatever process started ALSA, and it all mostly works.

If I recall correctly, some people hated pulseaudio before systemd even existed. I think some of the bad experiences with pulseaudio in fact informed early anti-systemd bias. People remembered how much they disliked pulseaudio and expected that, as another Lennart project, they would also hate systemd.
Back to top
View user's profile Send private message
crocket
Guru
Guru


Joined: 29 Apr 2017
Posts: 449

PostPosted: Sat Jan 11, 2020 12:28 pm    Post subject: Reply with quote

I don't hate systemd or pulseaudio. I don't use systemd because it often hung during shutdown. I stopped using pulseaudio because it was far simpler to make ALSA do what I wanted.

I'd rather watch the progress of pipewire than use pulseaudio. Pipewire might actually be able to transparently bridge all pipewire applications with JACK. Pipewire is able to pass its API calls to JACK. It has no overhead while pulseaudio jack sink has overhead.
If all applications that I use supported pipewire, I might start using pipewire.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum