Monthly Archives: July 2014

Eclipse Luna, SVN – problem with older Subversion 1.6 repositories !

Posted on by

In Eclipse I have to handle a variety of PHP projects (with additional natures) which are interconnected in different ways. E.g. my present project may for convenience have links to folders of another project in another Eclipse workspace. Such links exist in my case for example to files containing very basic classes of some of my own frameworks. In some projects I combine the present project work with upgrading the basic framework classes in parallel to a new level of capabilities. In such a situation I want to directly change the basic classes for all other projects that use them and test compatibility aspects.

The version control of almost all interconnected projects is done by Eclipse Subversive plug-ins from Polarion. The link situation on the folder/file side of my projects leads to so called external SVN relations on the SVN side of my interconnected projects. These relations are generated automatically by the Subversive plug-ins for Eclipse.

In some cases I may even have different SVN locations – some local, some on a dedicated SVN servers in the local network or on the Internet. Unfortunately, not all of my SVN repositories are of the same Subversion version – which was no problem as long as different connectors were available in Eclipse and the repositories were generated to be backward compatible. Some of my SVN repositories are relatively old ones – i.e. of SVN version 1.6. Mostly associated with framework classes I continuously have worked on for years.

From KDE’s SVN client “kdesvn” I am very familiar with the problem that e.g. a client for a Subversion version 1.8 is not able to deal with SVN repositories that were generated with an older version of Subversion (e.g. Subversion version 1.6). An error message including as “… working copy is too old …. “ is a typical indication of this situation. In this case it does not help that you may have set up the repository with backward compatibility (e.g. to SVN version below 1.6). You have to update your repository by using the command

svnadmin upgrade

inside the base directory of the repository. Which may be delicate – if you did not set up any backward compatibility your Eclipse plug-in may no longer be able to handle the repository.

So, before updating SVN in your Linux OS and upgrading your SVN repositories you should always check carefully, whether the Subversive SVN plug-ins in Eclipse will be able to handle the repository afterwards. Actually, already this type of problem indicates that a strategy to maintain SVN repository versions consistently should be followed. However, I am a bit lazy. And as long everything worked smoothly I had no reason to upgrade my SVN repositories to one and the same Subversion version.

Some days ago – due to some irritating errors of syntax highlighting in the Kepler JSDT module – I installed Eclipse LUNA (i.e. version 4.4.2.) instead of KEPLER. The JSDT highlighting error went away. However, I ran into deep trouble with the subversion plug-ins.

Actually, my Eclipse upgrade lead to a complete mess because of my laziness in the past to keep the different Subversion versions of SVN repositories on the same level. The following discussion may help others to recover from such a situation and reconsider a strategy to keep the Subversion versions of one’s SVN repositories consistently aligned.

Eclipse Subversive plug-ins for LUNA provide SVN Connector Kits for Subversion versions 1.7 and 1.8, only

Recently, I had started with a new PHP project in Eclipse KEPLER depending on a set of classes of one of my frameworks. So, I thought this project would be a good choice to get some experience with Luna. Without much thinking I had installed several Eclipse plugins I typically use into LUNA as PDT, WST, Mylyn, JSDT
Jquery , etc. and of course Subversion and Polarion Subversive SVN Connector Kits. So, I felt well prepared to open the my Kepler workspace with Luna.

The first thing you may stumble across when using Luna first time is that you should make a copy of your original PHP projects in the Kepler workspace directory. Luna will upgrade your Kepler project in a way that is not backward compatible to older Eclipse versions. Ok, that done, I wanted to share my upgraded project by using a SVN repository. I chose an existing local SVN location – based on the “file” sub protocol of SVN. Then I started to check in the directories and files of my project. The check in process seemed to work well in the beginning. But then I was bombarded with error messages. Besides other things the messages told me that subversion stumbled across an “unsupported working copy”.

Ok, I checked the installed connector versions of the SVN Polarion plug-ins and did additional research on the Internet – the connectors were for Subversion version 1.7 and 1.8, only! Others are not available for Luna! As I did not remember exactly the version of my local repository (probably 1.6) I disconnected the PHP project from SVN with allowing to delete all SVN information from disk.

Making a new repository for your present project may not help

Next thought: Well, lets make a new SVN repository then – of SVN version 1.8. I combined this step with setting up a local lightweight SVN server – because somebody had told me that the performance of the core SVN protocol would be much better than the “file” protocol. After the intermezzo of the server setup I manually created a new SVN database on my local SVN server (i.e. my workstation). As Subversion on the Linux workstation is of version 1.8 -I had no doubts that LUNA now should be able to work together with this SVN database. From Eclipse I shared my previously disconnected project by using the new SVN location with the generic “svn//” protocol. And started to check in again. Which started well and then ran into errors again … 🙁

To analyze what happened I set up a fresh independent project and filled it with some directories and files and tested SVN transactions with my version 1.8 SV repository. That worked perfectly! So, something obviously was wrong with my other more complicated project. A closer analysis showed what the reader may already have guessed:

The errors occurred during the check in process when directories were reached that were linked to my basic long term projects with their old repositories. Which on the SVN side are located in an “external” repository. So, my conclusion was:

One must first remedy the outdated working copy situation for the basic projects which your present project may depend on by links. Their (external) SVN repositories have to be upgraded first.

In complicated dependency situations you may run into more problems

Although the above conclusion is correct it may not directly lead to success. By walking through my projects and trying to get them working again with SVN under LUNA I stumbled across several situations which stressed my nerves. Among others there are 2 stupid things that may lead you to dead end situations and prevent a recovery from them with the Eclipse subversion tools:

  • After a trial to check in files into (too old) repositories there may be open outgoing SVN transactions left which cannot be resolved due to the impossibility to handle old SVN working copies of connected projects with linked folders. You are forced to completely disconnect your present project from the SVN repository with a deletion of all SVN information from disk (i.e. “.svn” files in the folders and sub folders of your Eclipse project)
  • In complicated link situations you may find the following: There may be a mixture of “.svn” files in a project which describe the diverse repositories of linked folders of other projects on different version levels. I found that with the present plug-ins of LUNA this may lead to unrevoverable SVN situations and even repository corruption.
  • Despite disconnecting projects and allowing for a deletion of SVN information some “.svn” files may remain at unexpected locations. This may depend of what kind of SVN trouble and corruption you had and what you tried to remedy the situation. The remaining “.svn” files may include old SVN version information – leading to trouble again when you try to connect to an SVN repository next time.

Eventually, I gave up and really tried to build my previous Kepler projects from scratch again under Luna. Including the SVN aspects.

Steps to recover and get a working LUNA – SVN implementation again

The following sequence of steps worked in my case:

  • First, make copies of your projects AND the associated SVN repositories. You never know ….
  • Check in all files and directories in all of your projects with the old Eclipse version (in my case Kepler) to get the latest versions into the existing SVN repository.
  • If one of the previous SVN repositories used under Kepler is corrupted (according to SVN messages in Eclipse) – do not use it any longer in the steps below. Build a new repository location instead.
  • Disconnect all existing Kepler projects from SVN via the context menu of the project by using the menu points “Team >> Disconnect” and allow for a deletion of the SVN information from disk.
  • Important point: Remove all remaining “.svn” files inside your Eclipse projects which may have remained there by using the command
    “find . -name “.svn” -exec rm -fR {} \;”
  • Go to the SVN repositories that still worked in Kepler (wherever they may reside) and upgrade by “svnadmin upgrade” consistently to the present SVN version – in my case 1.8.
  • Systematically restore your basic projects – i.e. the ones on which other projects may depend – from scratch by using the upgraded repositories. Or share these projects again with reference to the upgraded repository from which you then update the files to the latest repository version.
  • If one of the last steps is not possible due to repository corruption you build up new projects in Eclipse and fill them with the files from your (Kepler) project backups. Then share them by using a new repository location of your choice. Check that all SVN transactions work as expected for your basic projects.
  • Only then rebuild your more complicated projects depending which depend on your basic projects and share them again with the upgraded SVN repositories or newly generated ones.

And in the future:

Follow a systematic approach to upgrade your SVN repositories consistently to Subversion versions your Eclipse installation AND your other tools of your Linux desktop can handle.

Finally: Have fun with Eclipse LUNA and PHP or JS/Ajax projects. It feels great so far ….

Asus Xonar D2X unter Linux / Opensuse 13.1 – I

Posted on by

In meinem Linux-PCs habe ich seit ca. einem Jahrzehnt eine Audigy 2 Platinum am Werkeln, die mir schon seit OSS-Zeiten gute Dienste geleistet hat. Leider gibt es die Karte nur noch antiquarisch und auch die PCI-Slots werden auf modernen Mainboards eine Seltenheit. Aus diesem Grunde war ich seit längerem an einer Alternative interessiert.

Ein Bekannter von mir hatte im Frühjahr bei Amazon gute Testberichte zur Xonar D2X PCIe gelesen. Er hat sich schließlich die Karte gekauft und mich gebeten, sie auf seinem PC unter Opensuse 13.1 zum Laufen zubringen. Ich habe mir dann vorab erlaubt, zunächst auf meinem eigenen Systemen Tests durchzuführen. Inzwischen besitze ich die Karte selber.

RM_D2X_600

Daten zu dieser Karte, die 2008 auf den Markt kam und immer noch ca. 120 Euro kostet, findet man z.B. hier:

http://www.guru3d.com/articles_pages/asus_xonar_d2x_sound_card_review,1.html
http://sound-cards-review.toptenreviews.com/asus-xonar-d2x-review.html
http://www.bit-tech.net/hardware/2008/01/13/asus_xonar_d2x_pci-express_soundcard/1
http://www.hardwareluxx.de/index.php/artikel/hardware/multimedia/2255-asus-xonar-d2x.html?start=1
http://www.overclockers.co.uk/showproduct.php?prodid=SC-001-AS&tool=3
http://www.thinkcomputers.org/asus-xonar-dx2-sound-card-review/1/

Die Tatsache, das die Karte schon etwas älter ist, bewerte ich nicht als negativ – insbesondere nicht unter Linux. Es ist dann einfach wahrscheinlicher, dass die Alsa-Integration ausgereift ist.

Bevor ich in einem nachfolgenden Beitrag auf die Grund-Konfiguration unter Opensuse 13.1 eingehe, möchte ich an dieser Stelle zunächst ein paar Worte zur Anschaffung und Einschätzung der Karte verlieren. Vorausschicken will ich, dass ich zur Zeit ein reiner Audio-Endverbraucher bin und beim Arbeiten gelegentlich Musik sowohl über Lautsprecher als auch Kopfhörer höre.

Die Lautsprecher an meinem Arbeitsplatz entstammen einem in die Jahre gekommenen, billigen Inspire T7900 7.1 Speaker Set von Creative Lautsprecher. Eine optische Verbindung zu einer höherwertigen Stereo-Anlage mit Elac 4Pi Lautsprechern wird gelegentlich benutzt. Meistens höre ich allerdings Musik (Klassik, Jazz, Heavy Metal) mit einem Kopfhörer (Sennheiser HD600). Spiele und zugehörige Soundeffekte haben für mich kaum Bedeutung. Zum Spielen bleibt mir schlicht zu wenig Zeit – echter Surround-Sound spielt daher für mich keine entscheidende Rolle. Wohl aber ein UpMix von Stereo auf 7.1 Kanäle.

Alternative zur D2X: 24bit-Karten von Creative

Sowohl meine “Audigy 2 Platinum” wird durch passende Kernelmodule und Alsa unter Linux hervorragend unterstützt. Wie so oft, muss man allerdings Pulseaudio komplett abschalten, um in den Genuss einer vollständig und vernünftig bedienbaren Audio-Karte zu kommen. Zu Pulseaudio und seinen Bugs habe ich sowieso nur einen einzigen Kommentar: Bei Opensuse mit Hilfe von Yast >> Hardware >> Sound >> Andere” komplett deaktivieren und statt dessen mit “Alsa pur” arbeiten. 🙂

Auf einem anderen System PC nutze ich eine Creative X-Fi-
Platinum – allerdings ohne Creatives Frontpanel – und bin damit ähnlich zufrieden wie mit der Audigy 2. Auch hier ist der Einsatz unter Linux inzwischen relativ problemfrei. Angeblich soll ja die Klangqualität der X-Fi Titanium deutlich besser als die der Audigy 2 sein. Na ja, auf den bei uns angeschlossenen Lautsprechern hört man davon nicht so viel. Bei Benutzung von Kopfhörern werden die Unterschiede eher spürbar.

Vorteil der alternativen Creative-Karten

Unter Alsa kommt bei beiden Creative-Karten direkt ein großer Vorteil zum Tragen, der für KDE4 User durchaus von Bedeutung ist:

Höhen und Bass können mit Kmix direkt über den Audio-Prozessor der Creative Karten und damit systemweit geregelt werden.

Zu alten KDE 3.5 Zeiten hätte man darüber nur gelächelt. Die Elimination eines systemweiten Equalizers unter KDE 4.x hat mir das Lachen in der Vergangenheit eher vergehen lassen. Schließlich hat man im Normalfall keine HiFi-Anlage mit allem Schnickschnack an seinen PC angeschlossen. Eher eben irgendwelche Stereo- oder Surround-Speaker in der 100 bis 200 Euro-Klasse. Und dann will man doch gerne die Schwächen der Lautsprecher systemweit kompensieren. Eben durch einen Equalizer des Desktops – oder durch direkte Einstellungen der Soundkarte über Kmix. Dieses Problem ist auf Laptops mit kleinem angeschlossenem Lautsprecher natürlich noch drängender.

Etwas Ähnliches gilt zudem für die Kompensation nachlassender Hörfähigkeiten älterer Mitbürger, zu denen ich mich inzwischen selbst zählen darf (wir haben andere wichtige Qualitäten 🙂 ). Betroffen ist ja meist die Fähigkeit zur Differenzierung im Hochton-Bereich.

Den tragenden KDE-Entwicklern war das Thema eines systemweiten Equalizers aber leider egal oder zu uninteressant – trotz der Einführung der Zwischenschicht Phonon für darunterliegende Audio-Systeme. Gott sei Dank haben wenigstens die Entwickler der verschiedenen Audio-Player diesem KDE-Mangel für ihre eigenen Applikationen abgeholfen – siehe u.a. Clementine und auch Amarok. Ergänzend ist eine systemweite Höhen- und Tiefen-Regelung, wie sie die Audigy2- oder X-Fi-Titanium-Karten von Creative bieten, ein ganz brauchbarer Ersatz für einen fehlenden systemweiten Equalizer.

Zur Xonar D2X und ihrem Klangbild

Den Luxus einer systemweiten Höhen- oder Bass-Regelung wird man bei der Xonar leider nicht bekommen – jedenfalls nicht ohne zusätzliche Einbindung anderer Linux-SW-Module (wie z.B. Ladspa). Warum also doch die Entscheidung für die relativ teure Xonar D2X?

Ganz einfach: Es ist letztlich die für meinen Geschmack und mein Gehör die bessere Karte. Das merkt man aber erst, wenn man mal auf ein und demselben System sowohl die Audigy2, die Titanium als auch die Xonar D2X installiert hat und zwischen den Karten oder deren Ausgängen hin- und herschalten kann. Mit einem höherwertigen Kopfhörer. In meinem Fall durch einfaches Umstecken der Kopfhörer-Stecker und durch Umschalten unter Phonon.

Zu der in diesem Zusammenhang berechtigten Frage, wie man mit Hilfe von Alsa simultan Sound auf den Kanälen zweier installierter Soundkarten abspielen kann, siehe die Links ganz unten. Bei der Hörprobe sollte man natürlich alle Equalizer-Funktionalitäten irgendwelcher Player abschalten. Resultat:

Die Xonar D2X hat meiner Meinung nach ein klareres, konturreicheres Klangbild als die Creative Karten. Ich kann es nicht anders beschreiben. Die Verortung von Instrumenten wirkt präziser, schärfer. In jedem Fall gegenüber der Audigy 2 als auch gegenüber der XFi Titanium. Eine gute Platte zum Testen ist etwa “Grace” von Kjetil Bjørnstad. Tests von Heavy Metal Musik zeigen einen knackigen Bass, der nach meinem Gehör nicht so übertrieben und künstlich wie bei den Creative Karten daherkommt.

Der Rauschabstand ist mit 118 dB
hervorragend. Rauschen ist somit in der Praxis nicht wahrnehmbar.

Für wen ist die Xonar D2X etwas ?

Wer also sollte als die gut 125 Euro in eine Xonar D2X investieren? Aus meiner Sicht Leute, die Musik unverfälscht vom PC über einen hochwertigen Kopfhörer oder eine hochwertige Sound-Anlage hören wollen. Am besten im wav- oder flac-Format.

Die Karte lohnt sich keinesfalls für Spiele; sie lohnt sich definitiv auch nicht bei Einsatz billiger Lautsprecher oder Surround-Sets für PCs.

Was ist an der Xonar D2X störend?

  • Viel weniger Regelmöglichkeiten der Soundverarbeitung als z.B. bei Creative Audigy Karten
    Wir werden im nachfolgenden Artikel feststellen, dass das Spektrum der Regelmöglichkeiten der Karte unter Linux im Vergleich zu Creative-Karten sehr begrenzt ist.
  • Begrenzte Default Upmix-Möglichkeiten:
    Einen Upmix von Stereo auf 5.1, 6.1 bekommt man standardmäßig auch unter Alsa und Kmix nicht frei Haus. Unter Alsa und Kmix wird ein Upmix von 2.0 auf 2.1, 4.0, 7.1 angeboten. Diese Upmix-Varianten funktionieren auch. Will man für andere Situationen einen Upmix, muss entweder die Surround-Anlage dafür einen Schalter bieten – oder man muss etwas tiefer in die Alsa Konfigurationskiste greifen. Hierzu im nächsten Beitrag mehr. Das Thema Upmix lösen die Creative-Karten und ihre Treiber besser – nämlich über ihren internen Prozesssor.
  • Kein Front-Panel-Anschluss
    Es gibt keinen Front-Panel-Anschluss auf der Karte! Das ist völlig nervig! Auch für die Kopfhörer muss man hinten an den PC und ihre analogen Ausgänge! Und auch dort wird kein separater Ausgang angeboten, sondern eben der analoge Ausgang für die Front-Stereo-Kanäle. Da hängt ja aber im Normalfall eine analoge Verbindung zum Verstärker der Soundanlage dran – zumindest dann, wenn man dafür nicht den optischen Ausgang benutzen kann. Sprich: Wenn die Rückseite des PCs schlecht zugänglich ist, muss man sich einen Adapter/Schalter beschaffen oder basteln, der ein Umschalten erlaubt. Aus meiner Sicht ist das ein Design-Fehler!
    Gott sei Dank, hat der Verstärker für das Inspire T7900 7.1 Set einen beweglichen, kabelgebundenen Controller für die manuelle Regelung von Lautstärke und Bass – und an dem Teil befindet sich auch ein Kopfhörerausgang, der die Lautsprecher abschaltet. Damit muss ich die hinteren Anschlüsse der Karte für den Kopfhörer nicht benutzen.
  • Extra Stromanschluss mit veralteten Floppy Steckern erforderlich
    Die Karte erfordert einen zusätzlichen Stromanschluss per Floppy-Strom-Kabel – sonst weigert sie sich zu funktionieren. Ein entsprechendes Kabel wird jedoch nicht mitgeliefert. Ich selbst hatte solche Kabel aber noch vorrätig. Der Anschluss wirkt altertümlich; eine etwas wackelige Angelegenheit.

Sonstige Verarbeitung der Xonar D2X

Ansonsten gibt es an der Verarbeitung der Karte kaum etwas zu meckern. Für eine gute Abschirmung ist durch eine kastenartige EMI-Ummantelung gesorgt. Die kann wegen ihrer Ausdehnung evtl. bei voluminöseren Karten in der Nachbarschaft Probleme bereiten. Schwierigkeiten mit der Wärmeabfuhr konnte ich bislang nicht feststellen, obwohl die Karte direkt über einer Nvidia GTX 460 Grafik-Karte verbaut ist. Die analogen Anschlüsse hinten sind veredelt. Auf den Beleuchtungsschnickschnak – ja, die Anschlüsse leuchten in unterschiedlichen Farben ! – hätte ich allerdings auch gut verzichten können. Ist eher was für Modder.

Im nächsten Beitrag

Asus Xonar D2X unter Linux /
Opensuse 13.1 – II

stelle ich dar, wie die (einfache) Basis-Installation unter Opensuse 13.1 erfolgt und welche Regelmöglichkeiten z.B. Kmix danach für die Karte anbietet. Wir werden dann merken, dass die Einstellmöglichkeiten im Vergleich zu einer Audigy (leider) dramatisch geringer ausfallen. In einem weiteren danach folgenden Artikel
Asus Xonar D2X unter Linux / Opensuse 13.1 – III – Alsa Upmix 2.0 auf 5.1
liefere ich eine einfache “.asoundrc”-Konfiguration für evtl. Upmix-Probleme nach.

Links zum parallelen Einsatz mehrer Soundkarten unter Alsa

http://slack4dummies.blogspot.de/2012/02/alsa-multiple-output-multiple-sound.html
https://www.6by9.net/output-to-multiple-audio-devices-with-alsa/