Hi there.
MPD to brutefir is working since months!
( I just had a 24bit problem the other day, which is solved with a workaround - see Wiki)
There shouldn't be any problems to run brutefir, if you follow the examples in my
mpd-wiki. I also listed a brutefir config example.
Let me know if you need support or if the Wiki should be improved.
Cheers
MPD to brutefir is working since months!
( I just had a 24bit problem the other day, which is solved with a workaround - see Wiki)
There shouldn't be any problems to run brutefir, if you follow the examples in my
mpd-wiki. I also listed a brutefir config example.
Let me know if you need support or if the Wiki should be improved.
Cheers
hi all!
i hope this is the right place to post my question.
object: USB driver (snd-usb-audio) tweak
reference: http://www.diyaudio.com/wiki/index.php?page=LINUX+Audio+ALSAManualInstall
problem: the code in usbaudio.c is changed.
before:
now:
so, just change "ptmin" value?
it's safe?
thanks
i hope this is the right place to post my question.
object: USB driver (snd-usb-audio) tweak
reference: http://www.diyaudio.com/wiki/index.php?page=LINUX+Audio+ALSAManualInstall
problem: the code in usbaudio.c is changed.
before:
Code:
fp->frame_size;
}
}
/* set the period time minimum 1ms */
/* FIXME: high-speed mode allows 125us minimum period, but many parts
* in the current code assume the 1ms period.
*/
snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_PERIOD_TIME,
1000 * MIN_PACKS_URB,
/*(nrpacks * MAX_URBS) * 1000*/ UINT_MAX);
err = check_hw_params_convention(subs);
if (err < 0)
return err;
else if (err) {
hwc_debug("setting extra hw constraints...\n");
if ((err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,now:
Code:
fp->frame_size;
}
pt = 125 * (1 << fp->datainterval);
ptmin = min(ptmin, pt);
}
param_period_time_if_needed = SNDRV_PCM_HW_PARAM_PERIOD_TIME;
if (snd_usb_get_speed(subs->dev) != USB_SPEED_HIGH)
/* full speed devices have fixed data packet interval */
ptmin = 1000;
if (ptmin == 1000)
/* if period time doesn't go below 1 ms, no rules needed */
param_period_time_if_needed = -1;
snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_PERIOD_TIME,
ptmin, UINT_MAX);
if ((err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,so, just change "ptmin" value?
it's safe?
thanks
Here is a minor problem if you have more than one soundcard. (one onboard, one for serious audio, for instance)
they seem to get loaded randomly, so you never know which one will be adressed if you write hw:1,0.
I'm using ubuntu studio 8.10 and it's said to write a file 'sound' in /etc/modprobe.d with the content
option snd-<your-card> index=1
if you want it at hw:1
A cartlist command spills out: [EDIT: sorry, I meant 'cat']
0 [PST ] : Digi96 - RME Digi96/8 PST
RME Digi96/8 PST at 0xf1000000, irq22
What am I supposed to write in that 'option...' - line exactly?
Rüdiger
they seem to get loaded randomly, so you never know which one will be adressed if you write hw:1,0.
I'm using ubuntu studio 8.10 and it's said to write a file 'sound' in /etc/modprobe.d with the content
option snd-<your-card> index=1
if you want it at hw:1
A cartlist command spills out: [EDIT: sorry, I meant 'cat']
0 [PST ] : Digi96 - RME Digi96/8 PST
RME Digi96/8 PST at 0xf1000000, irq22
What am I supposed to write in that 'option...' - line exactly?
Rüdiger
What you do is following:
You edit:
sudo gedit /etc/modprobe.d/alsa-base
Then you lookup your drivers and assign the index. e.g.:
options snd-hda-intel index=1
options snd-usb-audio index=0
If you have more then one card assigned to one driver it'll work like that:
options snd-usb-audio index=0,2 vid=0x763,0x046d pid=0x2006,0x990
the vid and pid (vendor and product id) you find out by typing lspci or lsusb.
In this case my M-Audio Transit gets index 0 and my EMU0404USB gets index 2.
Hope this works.
You edit:
sudo gedit /etc/modprobe.d/alsa-base
Then you lookup your drivers and assign the index. e.g.:
options snd-hda-intel index=1
options snd-usb-audio index=0
If you have more then one card assigned to one driver it'll work like that:
options snd-usb-audio index=0,2 vid=0x763,0x046d pid=0x2006,0x990
the vid and pid (vendor and product id) you find out by typing lspci or lsusb.
In this case my M-Audio Transit gets index 0 and my EMU0404USB gets index 2.
Hope this works.
well... sorry, I don't quite agree with what you say in the WiKi about "block backup", "dd", etc. That may be useful (and perhaps the only option) to do a real working backup of a Windoze system. But Linux is not windoze.
Linux does NOT expect (let alone rely on) any file being on any particular place on disk(s). And it does not rely on any special "file attribute" either. Or any such stupid thing that some other systems do.
That is, you can "clone" a whole Linux system to another disk (or even another machine) just using plain "cp" (ok, plain "cp -a /sorce /dest" may be not the fastest / most efficient way of doing it... nonetheless it does work). Provided you change /etc/fstab accordingly on the "target" system afterwards, you may even change the partitioning scheme and/or the file system types in the process (try doing something like that with windoze, if you can...
).Thus (IMO) with Linux a "block based" backup - that is a disk image - has basically NO advantages over a "file-based" backup.
Quite the contrary, IMO. A "block-based" backup do have several disadvantages which actually makes it less practical and in a certain sense even somewhat less safe. The biggest problem being the fact that disk images can be restored ONLY on disks which are exactly identical to the one from which they have been obtained.
For mostly "static" data such as a music collection (or photo, videos, etc..), you need not make frequent backups - actually, unless you change something you may need to do it only once for each "group" of files (e.g. a new album, etc).
Thus, the event of a disk failure may happen a looong (in IT terms...) time after you've done the backup.
Say it happens a couple of years later. Do you think you'll be able to find a disk identical to one you bought a couple years before? No way. Even if you do find one, obviously buying one such disk would be completely anti-economic. For the same price (or probably less) you could buy a much larger one.
Moreover, although with Linux it's always possible to "loop-mount" a disk image to access some particular file(s), -say someone which gets corrupted or deleted by accident- just copying them back from a DVD or an HDD is easier...
BTW, IMHO for "static" data the best strategy is a "file oriented" backup on "ROM" (...of course actually "WORM") media such as DVDs. Though for large collections that's not very practical due to the large number of disks required.
On the other end, for mid-sized collections (up to a few TB) the easiest and most practical way is to use removable or external disk(s) and "rsync" to it. Notice I said easiest and most practical... NOT safest. HDDs are not really a safe long-term backup storage media. Lacking any viable and large enough "WORM" media, the good old tapes (currently DLT or LTO types) would still be much better than HDDs... wasn't it for the costs, which unfortunately are way too high for most of us.
BTW, I find it ridiculous and somewhat paradoxical that nowadays (at least up to a few TB) HDD storage space is much cheaper than tape space... but that's another story.
Oh, about backup on HDDs... SATA brought us some interesting things, like these: Tray-Less SATA Hot Swap Bay (see also some related discussions here).
Very handy... You save money buying only the "naked" HDDs and plug them in / remove them at will when needed. And of course data transfer will be way much faster than USB or FW...
UnixMan.
I am a bit confused about your negative attitude.
Non of your examples will let me backup and especially restore an entire drive except dd.
You would have to restore the MBR, partitons and partition-content (one by one).
This might not be an issue for an experienced Linux guy, but for a less experienced
person this is far more challenging, than just running a dd on the entire harddisk.
Even as experienced Linux guy you won't get a faster restore of a complete HDD, then using dd.
And don't forget many people do have mixed OS systems.
The rsync way I outlined quite well I guess. I am using it for all my disks on a day by day basis.
Cheers
I am a bit confused about your negative attitude.
Non of your examples will let me backup and especially restore an entire drive except dd.
You would have to restore the MBR, partitons and partition-content (one by one).
This might not be an issue for an experienced Linux guy, but for a less experienced
person this is far more challenging, than just running a dd on the entire harddisk.
Even as experienced Linux guy you won't get a faster restore of a complete HDD, then using dd.
And don't forget many people do have mixed OS systems.
The rsync way I outlined quite well I guess. I am using it for all my disks on a day by day basis.
Cheers
More on backups: rsync options...
I forgot to say...
* with "rsync" I usually use the options "-aHS".
* If you want to have an idea of progress, better use "-P" rather than "-v".
BUT... if you want/need max speed, consider using neither! In some cases writing a lot of lines on the terminal may slow things down...
I forgot to say...
* with "rsync" I usually use the options "-aHS".
* If you want to have an idea of progress, better use "-P" rather than "-v".
BUT... if you want/need max speed, consider using neither! In some cases writing a lot of lines on the terminal may slow things down...
soundcheck said:
Oh... sorry. I didn't meant to be "negative". I apologize.
there are also "partimage" and similar tools (not to mention non-linux based commercial offers such as "Ghost" or "TrueImage", of course).
so you are talking about system disk... I was thinking more about the music collection.
I think the two have very different characteristics and requirements and should be treated separately.
The system disk is relatively "volatile". Its data (at least part of it) may change quite often. So you need to back it up quite frequently. Fortunately, it's also not so much data.
On the other end, a moderately large lossless music collection may easily grow up to several TB of disk space... that's a rather HUGE amount of data (for an "home" installation, that is). Fortunately, it is basically "static" data. You will likely keep adding more and more new stuff to it, but the existing data may never change once added. Thus you need not to backup everything every so often, but rather keep an "incremental backup" of your archive, adding new stuff to the backup as soon as you add them to the collection.
To put it straight: unless you only have a relatively small collection that fits on a single disk together with the system, you MUST treat them separately. And even if that's not your case, keeping a separate incremental backup (possibly on WORM media) for static data is always a good idea.
Moreover, even in the case you have all on one large disk, what you'd do? copying say 1TB of data ("dd" just blindly copy everything, including empty space...) once every week? I don't want to be negative but c'mon, that doesn't seem a viable solution to me: "dd-ing" 1TB of data takes "forever".
HDD crashes and human mistakes (which cause accidental file deletion) do happen, and that's why backups MUST be done. But on average such accidents should not happen every so often. Yet you may never know WHEN they'll happen next. Thus, to be effective backups (of variable data) must be done quite often.
A solution which takes (at least) several ours to complete each and every backup is NOT a viable backup strategy, IMHO.
why not using at least some smarter tool such as "partimage" then?
Anyway, also partimage is convenient just for a small system disk or for some "once in a while" full backup of an HDD full of mostly "static" data.
Your suggestion may be ok only if you "require" to use at least TWO HDDs, a very small one (possibly a solid state "disk"!) for the "system" and another, large one for the music collection.
Nevertheless, for /home and the music collection I'd rather use some specific backup tool which is able to manage incremental backups (or at least rsync). One such tool may be e.g. "tob" (Tape Oriented Backup). But there are soo many of them...
use partimage, at least it will skip empty space...
BTW, speaking about Linux system disk, actually I don't care much about backing it up at all. It's all stuff which is always available elsewhere... I just happen to quickly backup configurations and customizations, as well as the list of installed package (as well as /home, of course... but that's done separately).
So I do backup (with rsync to removable storage and/or on DVD) /etc, /usr/local and /home plus /boot/grub/menu.lst , /var/lib/aptitude/pkgstates as well as the output of "dpkg --get-selections". If you have some databases (e.g. you use Amarok with mysql backend) you have to save a dump of the DB as well (you could backup the whole /var, but that's not a good idea). Of course, it's all done automatically by a trivial script.
Should the system disk crash, I do a fresh install (from scratch) of a minimal system. Then I restore /etc/apt and run
dpkg --clear-selections
dpkg --set-selections <myselections
and let apt install everything. Then I restore /var/lib/aptitude/pkgstates and the whole /etc, /usr/local/ and /home. Last come the DB dump, if any.
Indeed restoring this way does require much more work on my part... but that's not something that will happen so often: maybe just once in several years, maybe never ('cause nowday people happen to upgrade hardware before it has a chance to break.
).
soundcheck said:
Do you mean this:
Seems a bit short? I'm struggling to get mpd and brutefir working... assuming its my brutefir settings, could you show your brutefir whole configuration file?
This is probably a stupid question, but brutefir is started automatically by mpd right?
Many thanks!
Paolo.
I guess we don't differ too much. You just do it slightly different. I don't see any advantage though.
1. I did not intend to use any application, if I can run a backup from the command-line with a one-liner
2. dd output you can also run into a file. You don't waste any space if you're doing it this way.
doing it to a twin disk, will prepare you for shortest restore time.
3. Yes, I talk ablout system and data disk. And yes I agree that rsync is great to use for
data disks. Though it also works on system disks with certain limitations.
The other day I restored my system disk with rsync. This worked well.
As I said, rsync is less convienent if you face a real hdd-crash.
4. I btw descibred incremental backups with rsync which are more then trivial to accomplish
Cheers
I guess we don't differ too much. You just do it slightly different. I don't see any advantage though.
1. I did not intend to use any application, if I can run a backup from the command-line with a one-liner
2. dd output you can also run into a file. You don't waste any space if you're doing it this way.
doing it to a twin disk, will prepare you for shortest restore time.
3. Yes, I talk ablout system and data disk. And yes I agree that rsync is great to use for
data disks. Though it also works on system disks with certain limitations.
The other day I restored my system disk with rsync. This worked well.
As I said, rsync is less convienent if you face a real hdd-crash.
4. I btw descibred incremental backups with rsync which are more then trivial to accomplish
Cheers
breez said:
You might look at jconv: http://www.kokkinizita.net/linuxaudio/
it uses fir but itis more efficient
Tom
soundcheck said:
I figured it out. But it isnt very obvious from your guide, as the section on brutefir setup seems to just be about using fifo, there is no mention of using 'stdin', read that in a post of yours from another forum.
From the brutefir page in the wiki:
Where as you need to know to use:
Just an extra line in the MPD page saying this would make it a lot clearer....
On a different note, have you ever experienced MPD acting strangly? For some reason with my setup MPD decides to suddenly skip all the tracks in a playlist randomly.... hmmm.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.