Welcome!
Important information
-- Spectre and Meltdown vulnerabilities
-- Change in MX sources

News
-- MX Linux on social media: here
-- Mepis support still here

Current releases
-- MX-17.1 Final release info here
-- antiX-17 release info here

New users
-- Please read this first, and don't forget to add system and hardware information to posts!
-- Here are the Forum Rules

disk writes and alsa

Problems with your sound card are to be posted here, as well as tutorials to share with others.
Message
Author
grekim
Forum Novice
Forum  Novice
Posts: 4
Joined: Wed Mar 19, 2014 7:25 am

disk writes and alsa

#1 Post by grekim » Wed Mar 19, 2014 10:57 am

Hi, I am a developer of Linux audio software and I have noticed that Mepis does not cause an xrun with ALSA when data gets written to disk. I find this very interesting because plain Debian, Ubuntu, and even Crunch Bang with Openbox will cause an xrun during disk writes with software I am testing. So, it would be great to know what possible optimizations are in place in Mepis that are not in the other distros that might keep a disk write from stepping on ALSA. Aptosid is another Debian based distro that seems to avoid the problem as well. So, if anyone has an idea of what Mepis might have in common with Apstosid, that might be a clue. Thanks!

User avatar
dolphin_oracle
Forum Veteran
Forum Veteran
Posts: 9275
Joined: Sun Dec 16, 2007 1:17 pm

Re: disk writes and alsa

#2 Post by dolphin_oracle » Wed Mar 19, 2014 11:44 am

I'm not real sure, but do the other distro's you mention use pulse-audio server on top of alsa. MEPIS, antiX, and MX do not use pulse-audio, so that is one potential place to look.
http://www.youtube.com/runwiththedolphin
lenovo ThinkPad T530 - MX-17
lenovo s21e & 100s - antiX-17, MX17(live-usb)
FYI: mx "test" repo is not the same thing as debian testing repo.

User avatar
lucky9
Forum Veteran
Forum Veteran
Posts: 11380
Joined: Wed Jul 12, 2006 5:54 am

Re: disk writes and alsa

#3 Post by lucky9 » Wed Mar 19, 2014 11:46 am

Welcome to the forum grekim! :welcome:
Yes, even I am dishonest. Not in many ways, but in some. Forty-one, I think it is.
--Mark Twain

grekim
Forum Novice
Forum  Novice
Posts: 4
Joined: Wed Mar 19, 2014 7:25 am

Re: disk writes and alsa

#4 Post by grekim » Wed Mar 19, 2014 12:51 pm

Thanks for the welcome!
I was wondering about Pulse Audio. As far as I know the software is interacting directly with ALSA. If Pulse is working too then maybe I could stop it temporarily and see if that makes a difference. I always thought Pulse was maybe a convenience in some situations, but overall adding more compleixity and possibly inefficiency. What about disk drivers? Are there drivers added to Mepis? Thanks!

User avatar
lucky9
Forum Veteran
Forum Veteran
Posts: 11380
Joined: Wed Jul 12, 2006 5:54 am

Re: disk writes and alsa

#5 Post by lucky9 » Wed Mar 19, 2014 3:03 pm

grekim wrote:What about disk drivers? Are there drivers added to Mepis?
I (obviously) don't understand this question. What 'disk drivers' are you asking about.
Yes, even I am dishonest. Not in many ways, but in some. Forty-one, I think it is.
--Mark Twain

grekim
Forum Novice
Forum  Novice
Posts: 4
Joined: Wed Mar 19, 2014 7:25 am

Re: disk writes and alsa

#6 Post by grekim » Wed Mar 19, 2014 4:00 pm

Sorry, what I was wondering is if Mepis had some additional drivers or modules that allows the kernel to interact with a hard disk or controller that a plain Debian distro might be lacking. For example, maybe Debian uses a more generic driver to interact with the HD, whereas Mepis had a driver more specific to the hard drive. I know its a long shot, but I thought I would ask.
So in trying to understand more about Mepis, the Mepis kernel is a Debian kernel compiled with different options or optimizations, yes?
Thanks :)

User avatar
timkb4cq
Forum Veteran
Forum Veteran
Posts: 4346
Joined: Wed Jul 12, 2006 4:05 pm

Re: disk writes and alsa

#7 Post by timkb4cq » Wed Mar 19, 2014 4:05 pm

In MEPIS, as in other Gnu/Linux distributions, all the common disk drivers are part of the linux kernel. Some really old or odd drives might need a kernel module loaded that's not normally installed, but you wouldn't be booting up if that were the case.

One thing MEPIS does by default that some distros might not is that the username you give at install time is automatically added to the audio group, which gives you direct access to the sound devices. I know debian does not do this - and they have a good reason. It can break sound for other users in multi-user environments. But MEPIS is positioned primarily as a single-user desktop machine, not a server. Note that if you test to see if adding your user to the audio group helps in other distros, you won't see any change until a logout & log back in (or reboot).
MSI 970A-G43 MB, AMD FX-6300 (six core), 16GB RAM, GeForce 730, Samsung 850 EVO 250GB SSD, Seagate Barracuda XT 3TB

User avatar
lucky9
Forum Veteran
Forum Veteran
Posts: 11380
Joined: Wed Jul 12, 2006 5:54 am

Re: disk writes and alsa

#8 Post by lucky9 » Wed Mar 19, 2014 5:11 pm

I guess I did understand the question. So....what he said.
Yes, even I am dishonest. Not in many ways, but in some. Forty-one, I think it is.
--Mark Twain

grekim
Forum Novice
Forum  Novice
Posts: 4
Joined: Wed Mar 19, 2014 7:25 am

Re: disk writes and alsa

#9 Post by grekim » Wed Mar 19, 2014 7:32 pm

timkb4cq wrote:In MEPIS, as in other Gnu/Linux distributions, all the common disk drivers are part of the linux kernel. Some really old or odd drives might need a kernel module loaded that's not normally installed, but you wouldn't be booting up if that were the case.

One thing MEPIS does by default that some distros might not is that the username you give at install time is automatically added to the audio group, which gives you direct access to the sound devices. I know debian does not do this - and they have a good reason. It can break sound for other users in multi-user environments. But MEPIS is positioned primarily as a single-user desktop machine, not a server. Note that if you test to see if adding your user to the audio group helps in other distros, you won't see any change until a logout & log back in (or reboot).
Okay, thanks. Yes, I am up on adding users to audio group...good suggestion though. Maybe audio gets more of a priority in Mepis?
I do see that once installed, Mepis automatically makes a nice list of all partitions in /etc/fstab. And as I recall, most are mounted with the relatime option. I thought I explored that before with Debian, adding those options myself. I know when I mount manually, which I commonly do, I don't usually pass any options, so there may be something going on with respect to journaling.
I am also comparing the dirty page settings between Mepis and Debian and the only difference I see is Mepis is set at a 10% dirty_background_ratio while Debian is set for 5%.
I also hooked up an external drive with Mepis and recorded to that. It is fairly easy to hear when something is being written to the external this way. It appears that Mepis is writing roughly every 5-7 seconds. Whereas I think the problem distro's are waiting longer, such as the 30 second limit in the dirty_expire_centiseconds.

User avatar
BitJam
Forum Guide
Forum Guide
Posts: 2472
Joined: Sat Aug 22, 2009 11:36 pm

Re: disk writes and alsa

#10 Post by BitJam » Wed Mar 19, 2014 8:01 pm

grekim wrote: And as I recall, most are mounted with the relatime option. I thought I explored that before with Debian, adding those options myself. I know when I mount manually, which I commonly do, I don't usually pass any options, so there may be something going on with respect to journaling.
The "relatime" option is now the default so if you don't specify anything you get relatime. You can verify this via "cat /proc/mounts" after mounting a partition that is not in fstab using default options. But this should not be affecting your problem one way or the other, and it is not directly related to journaling.

I think you may be onto something with the values in /proc/sys/vm/dirty_*. I suggest using:

Code: Select all

head /proc/sys/vm/dirty_*
to see them all. It should be easy for you to verify that this is the source of the problem (and the path to a solution). If so, perhaps we could (someday, not today) make a little GUI for performance tuning. I would imagine that the slower settings extend battery life by sacrificing some real-time performance. Maybe a program like this already exists.

Post Reply

Return to “Sound”