TR Forums

@Forge -

Coming out the other side of the Great Linux Desktop Environment Apocalypse, I have finally made my peace with KDE. Yes, it is bloated; and yes, as a former happy GNOME 2 user I find some of KDE's default behaviors annoying. But RAM is cheap, and with a little poking and prodding it is certainly possible to bend KDE to your will. It is my default DE these days.

For lower-spec systems and VMs I often use LXDE instead of KDE, to minimize bloat. And Ubuntu's default Unity DE is actually fairly reasonable for older general-use laptops.

So we have someone new to Linux asking about setting up their first Linux install, and people start talking about LVM
Just remember, just because you can doesn't mean that you should

Well, I did state I consider myself somewhat of a power user, so discussion of more technical aspects don't surprise me. I don't mind, either, even if I probably won't use it for a while if at all.
Logical Volume Manager -- yeah, I think that may be overkill for what is essentially a workstation system. :-p

As for Cinnamon's ease of monitor hot-swap support, I think that may spoil me. This will be a portable system and while it will, hopefully, have a "built-in" monitor eventually, I can imagine needing to hook into a second display while running at times.
The desktop environment is probably what I'll change first. LXDE looks promising, though it is relatively "new" in comparison.

notfred wrote:

So we have someone new to Linux asking about setting up their first Linux install, and people start talking about LVM
Just remember, just because you can doesn't mean that you should

Quite true. It was more of a tangent to the XFS/ext4 discussion, really. Or maybe a tangent to a tangent.

For desktops I generally go with MD RAID-1 (no LVM). Now that SSDs have gotten cheap I typically put the root file system on an SSD and use the RAID-1 volume for /home, which simplifies installation a fair bit (no need to mess with MD during initial setup).

Getting (sort of) back on topic, another useful trick I've used a few times is to set up new Linux installs in a VirtualBox VM, tweak it until I'm reasonably happy with it, then image it to a physical hard drive. Once it is imaged to the drive the partitions can be expanded to use all of the space on the device, and then the drive can be moved to the physical system you are setting up.

If you do stuff like this semi-regularly you'll probably want to get a drive dock or hot swap bay...

I started setting up and installing more to Linux.

And I came across my first issue; stuttering audio. It's only on the analog, though I never heard quite this issue; it plays too fast, then waits (often producing "digital clipping"), then plays the next part too fast. With video, it will get ahead by a bit, then the video will stutter briefly, and the audio will start to get ahead again (asynchronous desynchronization, go figure.) And the best part -- it plays fine once there's a high enough load on the CPU.
I'm guessing this is some driver issue with the audio being processed in software. There's no driver to download, period, either from the motherboard manufacturer or the chipset manufacturer. It doesn't even show up on the latter's website. Perhaps it's a custom chip?
Sound is perfectly fine over HDMI, though I have to play the sound test after switching audio hardware to make it audible with applications. o_O

Also, I managed to get the NVidia driver installed! It was a few hours of looking through many text and video explanations, almost all with a different approach to "doing it right." I was stuck on the "X server is still running" error and finally figured that "sudo services lightdm stop" wasn't working because, since version 13, Linux Mint uses MDM, not lightdm. One "sudo services mdm stop" later and NVidia's installer was able to proceed.
Searching around wasn't a waste of time, though. I found out about the Ctrl-Alt-F1 key command. Interesting, but I think I'll only use it for updating the graphics driver.

Currently I'm fighting WINE with a few programs; hopefully I'll resolve those soon.

NovusBogus wrote:

Slackware

Oh wow! I haven't used Slackware since early 2000s. That brings back some memories. *long story for another time*


I haven't messed with linux since then, since I moved away from microsoft and novell networking and went more toward to ISP/Cisco-dudeness. My 72 year old mother uses a Windows 7 machine (and gripes about the speed all the time), and primarily just checks her outlook, surf the internet and go to virtual meetings, and sometimes uses Word, Excel, or Foxit.


Any linux distro out there that you folks would let your elderly mother use, that lets her do what she wants, without having it get in her way? As long as she can easily do everything she's doing now, and there's no retraining, I'm thinking about doing that for her. I guess basically, I wanna turn it into the linux version of a Mac. Easy to use, hard to screw up, once properly setup.

SonicSilicon wrote:

And I came across my first issue; stuttering audio. It's only on the analog, though I never heard quite this issue; it plays too fast, then waits (often producing "digital clipping"), then plays the next part too fast. With video, it will get ahead by a bit, then the video will stutter briefly, and the audio will start to get ahead again (asynchronous desynchronization, go figure.) And the best part -- it plays fine once there's a high enough load on the CPU.
I'm guessing this is some driver issue with the audio being processed in software. There's no driver to download, period, either from the motherboard manufacturer or the chipset manufacturer. It doesn't even show up on the latter's website. Perhaps it's a custom chip?
Sound is perfectly fine over HDMI, though I have to play the sound test after switching audio hardware to make it audible with applications. o_O

Yes, that's going to be a driver problem, it sounds they got the clocking wrong and it is running at 48kHz rather than 44.1kHz or similar.

The thing in Linux is basically all the drivers are built in to the distribution, generally motherboard and chipset manufacturers don't care about Linux. At most they will give the specs to the driver writers, but normally the driver writers are reverse engineering the hardware. What is the chipset and driver? There may be an option on the command line to fix this e.g. by forcing the clock rate to a particular value, or a Google search for that motherboard, Linux and sound may help.

Wow, weird. I haven't personally seen that sort of audio issue in the past 2-3 years; unless you've got a very new audio chipset (or one of the poorly supported Creative ones) things generally "just work" these days.

In the past I've seen some squirrely behavior with timing when the motherboard/BIOS has a buggy ACPI timer implementation, and the Linux kernel chooses (not sure how it decides) to use the ACPI timer as its high-resolution timing source. Could also be a bad interaction between the audio driver and the CPU's power management; that would explain why it depends on CPU load.

Things to try --

- Update to latest BIOS if you aren't already at the latest version.

- Temporarily disable CPU power management in your BIOS to see if that has any effect.

- If you have both onboard and a discrete soundcard, try temporarily removing the one you're not using (if you're using discrete disable the onboard in the BIOS; if you're using onboard, remove the discrete card).

- If you can figure out what audio chipset you've got we may be able to get a better handle on your issue. Run alsamixer in a terminal window; this should tell you what audio chipset the system thinks you have (and if it comes up as generic then we know a chipset-specific driver was not included in the distro you installed).

- Post the contents of the files /sys/devices/system/clocksource/clocksource0/available_clocksource and /sys/devices/system/clocksource/clocksource0/current_clocksource so I can have a look at them. Depending on what your motherboard supports and what the kernel is selecting by default, it might be worth trying to force the use of a different high-resolution timing device.

Anything modern should be using TSC for the clocksource, it's only older processors that have wacky TSC behaviours.

notfred wrote:

Yes, that's going to be a driver problem, it sounds they got the clocking wrong and it is running at 48kHz rather than 44.1kHz or similar.

I was trying to point out that the audio skipping only happens on analog, and only when the CPU load isn high enough / maxed. That should rule out a sampling rate mismatch.

The thing in Linux is basically all the drivers are built in to the distribution, generally motherboard and chipset manufacturers don't care about Linux. At most they will give the specs to the driver writers, but normally the driver writers are reverse engineering the hardware. What is the chipset and driver? There may be an option on the command line to fix this e.g. by forcing the clock rate to a particular value, or a Google search for that motherboard, Linux and sound may help.

The motherboard is an ASUS H97I-Plus, and its audio chipset is a Realtek ALC887-VD. There's no update driver on ASUS' site, and Realtek doesn't seem to acknowledge the existance of an 887 chipset, yet. (May be a custom IC for ASUS.)

just brew it! wrote:

Wow, weird. I haven't personally seen that sort of audio issue in the past 2-3 years; unless you've got a very new audio chipset (or one of the poorly supported Creative ones) things generally "just work" these days.

In the past I've seen some squirrely behavior with timing when the motherboard/BIOS has a buggy ACPI timer implementation, and the Linux kernel chooses (not sure how it decides) to use the ACPI timer as its high-resolution timing source. Could also be a bad interaction between the audio driver and the CPU's power management; that would explain why it depends on CPU load.

Things to try --

- Update to latest BIOS if you aren't already at the latest version.

I'm fairly certain it's the second most up to date version, the latest only adding overclocking features. The CPU is an i7-4790S, so I saw no benefit in installing the new BIOS version.

- Temporarily disable CPU power management in your BIOS to see if that has any effect.

There were a lot of clocking related settings in this BIOS. I'll try changing them when I get a chance.

- If you have both onboard and a discrete soundcard, try temporarily removing the one you're not using (if you're using discrete disable the onboard in the BIOS; if you're using onboard, remove the discrete card).

Nothing discrete, yet, unless you want to count the HDA (HDMI audio) on the GeForce, and the issue was present before installing that.

- If you can figure out what audio chipset you've got we may be able to get a better handle on your issue. Run alsamixer in a terminal window; this should tell you what audio chipset the system thinks you have (and if it comes up as generic then we know a chipset-specific driver was not included in the distro you installed).

See above.

- Post the contents of the files /sys/devices/system/clocksource/clocksource0/available_clocksource and /sys/devices/system/clocksource/clocksource0/current_clocksource so I can have a look at them. Depending on what your motherboard supports and what the kernel is selecting by default, it might be worth trying to force the use of a different high-resolution timing device.

available_clocksource:
tsc hpet acpi_pm

current_clocksource:
tsc

[addendum]I was seeing a behavior in the system monitor I never witnessed before. The cores were playing hot-potato with a 95%-100% utilization thread, cycling through them out of order. I only noticed it with one game so far (Red Eclipse) so I don't know if other applications are being treated the same.

ALC887-VD is the exact same audio chip used on my Asus M5A97 R2.0. Aside from the output level being a bit low to directly drive my headphones (which can be fixed by running a tool to flip the ALC887-VD's magic "enable internal headphone amp" bit after logging in), it works flawlessly in Ubuntu 12.04. So unless there's been a major regression in the Linux Realtek driver in the past couple of years the issue is not a compatibility issue with the ALC887-VD.

My M5A97 R2.0 is running with TSC as the clocksource too, and in general (as notfred noted) this should work. However, FWIW I do have at least one other system (somewhat older, it's a Phenom 1090T) where forcing the use of the HPET clock source seems to improve stability of timing-critical applications.

If you want to try forcing the HPET clock source to see if it makes a difference, open up your /boot/grub/grub.cfg file and find the menuentry stanza for the default kernel. This will typically be the first menuentry stanza in the file. Within that menuentry stanza, find the line that starts with "linux" and append the option
to it.

On next reboot the system should come up using HPET instead of TSC (you can verify that this is the case by examing the current_clocksource file again).

The grub.cfg options will revert to their defaults the next time grub.cfg gets regenerated; this typically happens because you've installed a software update that includes a new kernel. So if you decide you want to make the change permanent you will need to edit /etc/default/grub as well.

It's probably one of those cases where one variable was used, then they added another, and now both work identically (for now, until someone changes something), but I've been using clock= instead of clocksource=

My kernel string, apropos only to my laptop with SSDs, is pcie_aspm=force elevator=noop clock=hpet

And /sys/devices/blahblah/current_clocksource is "hpet".

Forge wrote:

It's probably one of those cases where one variable was used, then they added another, and now both work identically (for now, until someone changes something), but I've been using clock= instead of clocksource=

Yeah, it appears that "clock" is now deprecated. The "clocksource" parameter is the recommended method for overriding the kernel's automatic clock source selection.

Changing the BIOS setting for Intel Speedstep to disabled did not clear up the analog audio, nor did any other CPU clock / speed related setting.

When I tried to add the clocksource=hpet into grub.cfg the system was simply given a "no write access" error. That was with gedit and notepad. Going into the terminal, using "sudo edit" couldn't even open the .cfg -- it stated it didn't recognize the mime-type, and tried treating it as "application/octet-stream", then gave this error:
Error: no "edit" mailcap rules found for type "application/octet-stream"

Poking around for other solutions, it seems that since the debut of ALC887-VD, it has given issues under Linux. I am just about ready to try a USB audio solution I have around just to see if that works. Needs a new jack soldered onto it first.

Well, as noted above I have not had any significant issues with the ALC887-VD, so it is either something specific to the distro you are using, or your motherboard.

Yes, you do need to elevate to root to edit any system configuration files on Linux. Sorry, I should've mentioned that; once you've used Linux for a while you take stuff like that for granted. Try using "sudo gedit" or "sudo nano" to edit the config file. Also, you may want to copy the file to something like grub.cfg.original before editing it, to make it easier to revert if there is an issue.

As an aside, I tend to just elevate an entire terminal session with "sudo -i" (or "su" on non-sudo systems like vanilla Debian), then use vi to do config file edits. But I'm a vi user going back to the days of the dinosaurs; it can be rather counter-intuitive if you haven't used it before. The upside of learning vi is that it is guaranteed to be pre-installed on every major distro, regardless of which GUI is installed (or even if there's *no* GUI installed, as with, say, a VPS-based cloud system or headless fileserver). There's some pretty arcane sh*t in vi, but the basics (insert, delete, edit) aren't *too* bad!

I'm an xemacs man myself <flame war!!!> but I do the root user vi stuff for simple config file edits. If you have never used vi before you don't want to start with editing your config files. vi is not a WYSIWYG editor, instead it is a "You Get What You Asked For Even If You Didn't Mean It" editor.

notfred wrote:

I'm an xemacs man myself <flame war!!!> but I do the root user vi stuff for simple config file edits. If you have never used vi before you don't want to start with editing your config files. vi is not a WYSIWYG editor, instead it is a "You Get What You Asked For Even If You Didn't Mean It" editor.

No flame war, I fully admit that vi is insane by modern standards! When you realize that its UI dates back to the '70s, when people were still figuring out how editing files on a CRT terminal (as opposed to a hardcopy terminal) should work, I guess that isn't too surprising. Really, the only things it has going for it these days are that it is available (and typically installed by default) on all flavors of *NIX, and that it doesn't require a graphical desktop.

Well, I think I've ruled out clock issues:
Managed to get the clocksource changed to hpet (checked in current_clocksource) and -- the exact same issue persists.
I was planning on adding a sound card or USB audio adapter, later, but was hoping the on-board audio would at least be there to fall back on in case an issue arose. I think I have run out of patience with troubleshooting this ALC887, for now.

just brew it! wrote:

notfred wrote:

I'm an xemacs man myself <flame war!!!> but I do the root user vi stuff for simple config file edits. If you have never used vi before you don't want to start with editing your config files. vi is not a WYSIWYG editor, instead it is a "You Get What You Asked For Even If You Didn't Mean It" editor.

No flame war, I fully admit that vi is insane by modern standards! When you realize that its UI dates back to the '70s, when people were still figuring out how editing files on a CRT terminal (as opposed to a hardcopy terminal) should work, I guess that isn't too surprising. Really, the only things it has going for it these days are that it is available (and typically installed by default) on all flavors of *NIX, and that it doesn't require a graphical desktop.

I've heard from at least one Old Sysadmin that you should learn ed(1) as well because there are some lurching dinosaur systems that don't have vi but do have ed, or do have vi but it's not guaranteed to work if you can only mount the root filesystem, while ed is.

bthylafh wrote:

I've heard from at least one Old Sysadmin that you should learn ed(1) as well because there are some lurching dinosaur systems that don't have vi but do have ed, or do have vi but it's not guaranteed to work if you can only mount the root filesystem, while ed is.

I mean... this is a "possibility" but I can't imagine the OP every comes across such a situation. Unless he intends to go from Linux noob to guy fixing boxes that have been unsupported for 15+ years.

slowriot wrote:

bthylafh wrote:

I've heard from at least one Old Sysadmin that you should learn ed(1) as well because there are some lurching dinosaur systems that don't have vi but do have ed, or do have vi but it's not guaranteed to work if you can only mount the root filesystem, while ed is.

I mean... this is a "possibility" but I can't imagine the OP every comes across such a situation. Unless he intends to go from Linux noob to guy fixing boxes that have been unsupported for 15+ years.

Probably more like 25+ years.

just brew it! wrote:

Really, the only things it has going for it these days are that it is...

...amazingly awesome.

I do use vim more then straight vi, but it's still a beastly workhorse that's hard to beat.

NANO! (the war cry of the "special" children whenever the vi/emacs wars flare up, because I couldn't care less what the greybeards are all honked off about, I just want a gorramn editor that EDITS TEXT, and as simply as possible!!!!)

just brew it! wrote:

slowriot wrote:

bthylafh wrote:

I've heard from at least one Old Sysadmin that you should learn ed(1) as well because there are some lurching dinosaur systems that don't have vi but do have ed, or do have vi but it's not guaranteed to work if you can only mount the root filesystem, while ed is.

I mean... this is a "possibility" but I can't imagine the OP every comes across such a situation. Unless he intends to go from Linux noob to guy fixing boxes that have been unsupported for 15+ years.

Probably more like 25+ years.

It was in the context of being a professional sysadmin, not a proto-enthusiast. I was running with "learn vi because everything has it" tangent.

This might be confirmational bias, but this post about ALC887 issues seems too similar to ignore:
http://www.ubuntuask.com/q/answers-12-0 ... 02468.html
The short version; ALC887 has issues when running under Linux with either Intel HDA or NVidia HDA. Maybe temporarily unloading the HDA drivers will allow the 887 to work properly, but I haven't searched that far, yet. This situation reminds me of Sound Blaster Live and Voodoo2 (I think that was the combination) not working together under the original Unreal Engines.
Would be nice to have more than stereo on any of the audio options, though.

I've been spending most of my time stuggling with WINE, mostly dealing with its inability to deal with multiple cores. (You would think that, after at least eight years with this situation, someone would have started rewriting the code base.) Weirdest part was with the original Unreal Tournament; worked fine, and then it wouldn't -- I tried many configurations without it loading up again. In the end I stopped changing settings and now it just seems to either cycle between three failing states or just boot perfectly fine, randomly. I think I can live with that over the issues I had with my old system of a) throwing a GPF if I had left fullscreen when a new map loaded and b) waiting forever for the server browser to start populating.

SonicSilicon wrote:

The short version; ALC887 has issues when running under Linux with either Intel HDA or NVidia HDA.

Interesting. That could also explain why I haven't had issues, since my motherboard has an AMD chipset.

If you feel like trying to build a driver from Realtek's Linux driver source tarball I can probably walk you through it. Even though the 887 isn't listed on their site, the driver is pretty generic and should (in theory) work with all recent Realtek audio chipsets. There's a potential (minor) gotcha with this approach though; Realtek's custom driver installation replaces much of the generic ALSA stack with Realtek's version, which IIRC is missing the drivers for non-Realtek sound chips. So if you do this then decide to switch to another sound card down the road you will probably need to re-install ALSA.

I'd try using a newer kernel for the newer modules before trying the realtek drivers, usually, although I'm not positive on mint, you just need to enable backports to get a more current kernel. Easier to back out of than replacing large parts of alsa with your own compiled stuff. I compile lots of stuff, but it can be a real pita to undo once you go that route... Especially if that doesn't fix the issues.

Just an idea, but it might be worth looking into a sound card. If the onboard stuff is that finnicky and issue-ful, a discrete card can fix those problems. As a bonus, an awful lot of really nice cards lost Windows support years ago, but still work great under Linux. A bunch of Turtle Beach and Aureal's stuff comes to mind, you might even have something laying around.

With Windows, generally newer stuff works better. With Linux, I've often found that the oldest things you have that are capable of the job you want to do are often the best fit.

I've been trying to get an Windows program running in 64-bit under Wine, but it seems that I have to compile my own 64-bit version to get in running under Mint? GCC is something that I've used in the distant past and only sparingly, so the thought of using it to create a executable is a tad daunting, especially since I know there are patches I'll need to implement. I've never touched a .DIFF before, so if anyone has a good guide on this, it would be greatly appereciated.